|
Re: T41 receive attenuator working?
Bill's right: you do not have the correct address for the MCP23017 chip. The I2C address is set by JP15, JP16 and JP17.
?
?
The command "#define RF_MCP23017_ADDR" sets the address that the code looks for -- make sure the address in software matches the address you set using the solder jumpers.
|
|
Re: T41 receive attenuator working?
The control MC23017 is not recognized on the board so its not gonna work no matter what. ALSO MAKE SURE THAT THE .CPP and .H FILES FOR RF CONTROL ARE PRESENT IN THE FILE YOU ARE COMPILING. If they are not, there is no RF control software.
toggle quoted message
Show quoted text
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: www.VillaGrandPiton.com Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. email: bill@... -----Original Message-----
From: [email protected] <[email protected]> On Behalf Of jerry-KF6VB Sent: Monday, February 3, 2025 3:46 PM To: [email protected] Cc: D Solt via groups.io <davesolt@...> Subject: Re: [SoftwareControlledHamRadio] T41 receive attenuator working? On 2025-02-03 13:32, D Solt via groups.io wrote: I wonder if my problem with the attenuator is related to software.You can scope the control wires going to the attenuators. They're just DC levels. For the receive attenuator, the signals are U21 pin 21 ( .5dB ) through U21 pin 26. High = near 3.3V, Low = near 0V. - Jerry, KF6VB All 3 of my boards behave the same. They receive well, but the levels |
|
Re: T41 receive attenuator working?
¿ªÔÆÌåÓýNo¡ looks like the control is not talking on the RF board.? ? Here is a list of the reserved addresses (NOTE DON¡¯T get hung up on 1st receiver or Second receiver¡ they could be either by changing some definitions in the software) : ? ??? <- open the I2C address assignments spreadsheet. ??Column ¡°G¡± ? ? Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: ? Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. ? email:? bill@... ? ? From: [email protected] <[email protected]> On Behalf Of D Solt via groups.io
Sent: Monday, February 3, 2025 3:32 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] T41 receive attenuator working? ? I wonder if my problem with the attenuator is related to software.? All 3 of my boards behave the same. They receive well, but the levels never change when I adjust the receive attenuator.? Maybe I have an earlier version of the software or the I2C addresses are not right.? My Bit Report shows: 0x21 Front Panel 0x24 BPF 0x27 FR MC23017 NOT FOUND 0x6F RF 0x25 LPF 0x29 LPT Does this look correct?? I'll download the latest version of the SW tomorrow. ? dave ? On Fri, Jan 31, 2025 at 6:14?PM Oliver KI3P via <oliver=[email protected]> wrote:
|
|
Re: Not Displaying the Frequency....
You're right. Tell you what: I work on being less defensive if you are more thoughtful in your word selection when criticizing the T41 Project. The T41 is not my project. It is the distillation of the effort of hundreds of other people working in concert to make a better radio. To my knowledge, you are the only person out of more than 3200 who have said the tuning is unusable. The tuning IS usable. It's just not working the way you want it to...and that's fine. Just don't chuck the effort by me and others into the dustbin by making a statement that it's unusable. Instead, provide encouragement that suggests a path to make it better without tossing the work into the ashcan. Jack, W8TEE
On Sunday, February 2, 2025 at 03:16:09 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 12:04, jjpurdum via groups.io wrote: > Working toward minimal audio disruption from display changes will > make > the tuning useable - but still not nice > > Why would I _not _get that impression? To imply something is > "unusable" clearly implies that the T41 Project is currently unusable. Not the project, just the tuning.? It works great once you get where you're going.? It's quite an achievement, Jack.? You deserve kudos for bringing it to us. ? Don't be so defensive. ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB -- Jack, W8TEE |
|
Re: Not Displaying the Frequency....
Working toward minimal audio disruption from display changes will make the tuning useable - but still not nice Why would I not get that impression? To imply something is "unusable" clearly implies that the T41 Project is currently unusable. Since Al and I were the initiators of the project, I think the implication is pretty clear. Why would I not want to work on it if the implication that the current turning isn't usable? I don't know how many others share your assessment of the T41, but I'm glad your working on it. Keep us posted on your progress. Jack, W8TEE
On Sunday, February 2, 2025 at 02:52:02 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 11:17, jjpurdum via groups.io wrote: > I'm glad you are working on it, especially since you think it is an > easy fix, and hope others are too. That's why it's Open Source. > However, your comments imply that I have an infinite amount of > programming time or that your issue is the top priority. *** Jack, I am not asking you to work on it.? I am working on it right now. What on earth gave you the impression that I was asking YOU to work on it? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB -- Jack, W8TEE |
|
Re: Interesting board
¿ªÔÆÌåÓýIt already has a WIFI block onboard and an minipci bus too.? Amazing little board.? The documentation says Verilog is the right tool for programming. ? ? Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: ? Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. ? email:? bill@... ? ? From: [email protected] <[email protected]> On Behalf Of J P Watters via groups.io
Sent: Sunday, February 2, 2025 12:41 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] Interesting board ? Dr. Bill, ? In yeterday's Mouser delivery, there were a couple . I will have to look at the ? I am intrigued with the OnBoard HDMI Interface. It looks like a mini-hdmi to HDMI cable would? make it work.? Adding the W550 Ethernet Shield might be the way to add Ethernet Connectivity. ? On an interesting note, one of the Hermes Variants, the , is based on the Cyclone 10. The link is to the ? We will have to see if the RadioBerry development will lend itself to using the MKR VIDOR 4000. ? ..jpw J P Watters KC9KKO Morris, IL USA ? ? ? |
|
Re: Interesting board
¿ªÔÆÌåÓýThanks for the update.? Yep. I¡¯m very familiar with the Radioberry.? I have a couple of them and they work flawlessly.? Using the Radioberry and the Hermes projects as examples, I¡¯m convinced that long-term MY MAIN board will transition to an FPGA that runs full time processing frequency slices (read that as processing I/Q into audio, and generating I/Q from audio, and, separately generates and updates a waterfall display) while the rest of the minutia is processed in something else¡ but both driven by the requirements of the design.? That makes my radio very close to what you might consider is a FLEX on steroids¡ yet I built it with my hands.? I also think that if it were done right, it could be the back-end of many future radios (take the place of a fast PC with a high-end audio card running software like ¡°SDRConsole¡± and some hardware specific control routines sufficient to run the radio its connected to).? The T41 could have been (and can still be) divided into two parts in this way.? I think the part getting to generating I/Q from RF (demod) and I/Q from audio (mod) is there already. ? NOW UNDERSTAND THIS IS JUST ME¡ Pertains to NO ONE ELSE.? You won¡¯t see FPGA Main boards for sale anytime soon if at all. ? Yes the HDMI connection on the MKR board strikes my fancy too.? It¡¯s the only Arduino I know of that has an HDMI connection¡ and of all things I have a 10+ inch HDMI touch display sitting here that I use with one of my Radioberries that could easily be repurposed:? ? ? Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ VP2EHZ ? Owner - Operator Big Signal Ranch ¨C K9ZC Staunton, Illinois ? Owner ¨C Operator Villa Grand Piton ¨C J68HZ Soufriere, St. Lucia W.I. Rent it: ? Moderator: North American QRO Group at Groups.IO. Moderator: Amateur Radio Builders Group at Groups.IO. ? email:? bill@... ? ? From: [email protected] <[email protected]> On Behalf Of J P Watters via groups.io
Sent: Sunday, February 2, 2025 12:41 PM To: [email protected] Subject: Re: [SoftwareControlledHamRadio] Interesting board ? Dr. Bill, ? In yeterday's Mouser delivery, there were a couple . I will have to look at the ? I am intrigued with the OnBoard HDMI Interface. It looks like a mini-hdmi to HDMI cable would? make it work.? Adding the W550 Ethernet Shield might be the way to add Ethernet Connectivity. ? On an interesting note, one of the Hermes Variants, the , is based on the Cyclone 10. The link is to the ? We will have to see if the RadioBerry development will lend itself to using the MKR VIDOR 4000. ? ..jpw J P Watters KC9KKO Morris, IL USA ? ? ? |
|
Re: Not Displaying the Frequency....
See below: Jack, W8TEE
On Sunday, February 2, 2025 at 01:13:05 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 07:25, jjpurdum via groups.io wrote: > Character displayed in first position, character displayed in second > position - etc.? Then > > erase and rewrite ONLY those characters that have changed. > > Updating the characters used in the frequency display uses very little > time. *** Yet it is very disruptive to the audio.? Why is that?? I think it's because interrupts are disabled during SPI transfers. I don't know. The writing of the frequency is done by ShowFrequency(). You might try commenting those calls out to see if one is more "sensitive" than the others and that might lead you to what's really causing the delay. ? Tracking what has changed and what hasn't changed would likely > take more time and updating the entire string. *** Microseconds.? Literally zilch.? And during the process of this figuring, interrupts are open, and the audio continues. ? The real time eater is > the updating the spectrum/waterfall displays. The waterfall is less of > an issue because it's only changing 1x512 pixels on each pass. *** For some reason - that I don't really understand - the spectrum/waterfall is not a problem. ? I *suspect* that we are leveraging an internal function of the display to do partial scrolls or block moves. I do use the Block Transfer Engine in the spectrum display code to make it as fast as I can. > Since you can "see" which signals are active, I'm less concerned about > the audio _while _tuning than the audio when you _stop _tuning. *** Jack, I respectfully disagree.? Smooth tuning is VERY important.? When I'm zeroing in on an SSB signal or tuning past a CW signal, I want to hear it. Tuning around with my ancient Signal/One is more pleasant than tuning around with the T41 - although once you get there, the T41 receives better. I think we have different ideas on what "smooth tuning" is. To me, that means the frequency changes without "jumps". To you, it has something to do with the audio while tuning. Also, as I tune the CW section, I can hear the stations as I tune past them, so maybe we scan the band at vastly different rates.? ? Personally, at least half the time I spend in front of a ham radio is just tuning around.? The equipment manufacturers understand this:? Just think of all the elaborate main tuning mechanisms that have been used over the years. ? ? I think that the tuning can be seriously improved without loading down the radio to any appreciable degree.? Just leaving out the update of the inactive VFO is making a big difference.? Tuning only affects the main VFO.? Why are we erasing and rewriting the inactive one - that doesn't change while tuning? That would be easy to omit by just looking at the activeVFO variable. However, as you mentioned, not much time is spent writing the frequency info so I doubt that's main cause of the problem. ... let those people who think optimizing is so easy > make the improvements to those things that are working. *** Working on it Jack.? I am not a guy who takes software challenges lightly. Not any sort of programming genius or cowboy.? But I don't think this particular one is too hard.? I did embedded software for a living for 20 years, and developed a pretty good nose for what's hard, and what's not hard. I'm glad you are working on it, especially since you think it is an easy fix, and hope others are too. That's why it's Open Source. However, your comments imply that I have an infinite amount of programming time or that your issue is the top priority. It is not. Al and I have been working on the Calibrate routines which are much more urgent. We almost are ready to release the new Calibrate routines and those changes, while perhaps not looking difficult, took over 6 man-months to write and test. Maybe that's a condemnation of our skills, maybe not. It's easy to criticize someone else's work, but to replace it with your own code is a little more difficult. I do hope you can improve it and will share it with all of us. That's what Al and I have been doing for almost 7 years now. ? The first most obvious thing is to have a global variable for each display item that tells us *WHAT IS BEING DISPLAYED NOW*?? If the new thing to display is the same as what's being displayed now, we don't mess with it.? Why change it if it's already right? I agree. But you will have to add code to test the current state of the display and that will take time. The question is, which is faster. Disaggregation should help, but I would like to do it without adding to the globals list...there are already too many globals. ? Working toward minimal audio disruption from display changes will make the tuning useable - but still not nice.? Disagree. Your statement asserts that tuning is not usable, but that is false. You may not like it in its current state, but to say it's not usable is simply not true. To make it *nice* we will need to look at the big fat *tick* that happens at every encoder event.? That is IMHO a harder nut to crack.? But I remember the old encoder system with the encoders directly connected to a couple of I/O ports as being much smoother. The encoders are still directly coupled to the I/O ports. The difference is that the the main tuning is polled rather than driven by an interrupt. I discussed the change why earlier in the week. ? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB -- Jack, W8TEE |
|
Toroid Winding
All: I'm winding the toroids for a new LPF board. Because the filter might be used with Bill's 100W PA, the wire size is increased to #20 gauge for winding on T68 cores. Because of the thicker wire and relative small cores, the Crochet Hook method suggested in the QST article doesn't work very well and runs the risk of kinking the wire. Therefore, I'm back to "hand-winding" the toroids. FWIW, I've found that after I've threaded the wire through the center of the core, placing the wire between my thumb and forefinger, with the forefinger "on top" of the wire and gripping tightly and pulling the wire taught with my thumb "under" the wire tends to curl the wire that makes threading it through the center for the next turn much easier. The curl thus formed is in the direction of the next turn and makes kinking less likely. Jack, W8TEE -- Jack, W8TEE |
|
Re: Not Displaying the Frequency....
Character displayed in first position, character displayed in second position - etc.? Then erase and rewrite ONLY those characters that have changed. Updating the characters used in the frequency display uses very little time. Tracking what has changed and what hasn't changed would likely take more time and updating the entire string. The real time eater is the updating the spectrum/waterfall displays. The waterfall is less of an issue because it's only changing 1x512 pixels on each pass.? The spectrum display is more difficult because it updates the entire 150x512 pixel area. At each point in that display you must first erase the old pixel and write the new pixel. If they are the same, no write is needed. However, I don't know which is quicker: 1) just rewrite the old and new pixel, or 2) test the two values and only rewrite if they are different. Since you can "see" which signals are active, I'm less concerned about the audio while tuning than the audio when you stop tuning. Given a finite amount of time, I need to devote my time to those things that don't work than to optimizing those things that do work. After everything is working, then go back and optimize those things that can be improved. The other path is to continue to fix things that aren't working and let those people who think optimizing is so easy make the improvements to those things that are working. Jack, W8TEE
On Sunday, February 2, 2025 at 12:05:39 AM EST, jerry-KF6VB <jerry@...> wrote:
Things are a little improved.? There is a call to tft.fillRect() that erases the area where the frequency is displayed.? Theorizing that audio interrupts are held back while that's done, I split it up into 5 fillRect()s.? So - clear this little bit, then come up for air and let the audio go.? Then clear the next little bit, then come up for air... etc. I disabled updating VFO-B, and divided the clear of the current frequency into 10 mini-clears.? Much Better!? The audio is still chunky, but you can hear what you're tuning past. ? An obvious next step is to *selectively* rewrite stuff.? Why erase and rewrite stuff that hasn't changed?? Keep a string variable "displayed frequency".? Or to make it even simpler, have an array of 8 bytes:? Character displayed in first position, character displayed in second position - etc.? Then erase and rewrite ONLY those characters that have changed. ? ? ? ? ? ? ? ? - Jerry, KF6VB On 2025-02-01 20:39, jerry-KF6VB wrote: > I suspect I understand...and it's not good. > > I think that SPI requires precise timing, and audio interrupts are > disabled during long video transfers. > > Yet... the audio works fine while the spectrum, the S-meter bargraph, > and the waterfall update.? Sigh. > >? ? ? ? ? ? ? ? ? - Jerry, KF6VB > > > > > On 2025-02-01 18:50, jerry-KF6VB wrote: >> ...When tuning. >> >>? The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is >> unpleasant.? As you tune around, you get tiny >> blips of sound, interspersed with long display updates.? You basically >> cannot hear what you're tuning past. >> >>? I just tried commenting out the bit of code that displays the >> frequency as you tune.? Tuning is much better. >> There is still a burst of nasty noise with each encoder *tick*, but >> it's short, and you can easily hear what you're >> tuning past. >> >>? Naturally, that's not a real fix.? The instant you start tuning, the >> frequency display is wrong...and that's just wrong! >> >>? What would be a fix?? A few things:? First of all, we *could* do a >> timer thing where we don't bother to display >> the frequency until we stop tuning.? There was tuning, and now there >> isn't?? Ok, display where we got to.? Still not optimal. >> >>? I note that it always updates ALL the digits of the frequency, even >> those that haven't changed.? It even >> redisplays the VFO B frequency.? Surely it doesn't need to update all >> that. >> >>? Also - I wonder why on earth the audio pauses or stops or gets >> discarded while it writes the display?? Surely >> audio interrupts can continue during this time....? >> >>? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB >> >> >> > > > -- Jack, W8TEE |
K9HZ
jjpurdum
Johnny AC0BQ