Topics

one_stop_setting debugging #v6

Reed N
 

This is a discussion I'm splitting off from https://groups.io/g/BITX20/message/74440 and https://groups.io/g/BITX20/message/74449, where Joel and Armando indicated that the software branch https://github.com/reedbn/ubitxv6/tree/one_stop_settings wasn't working for them.

Hey guys. I did some testing, but it didn't turn up any obvious issues, so I'm really not quite sure why the one_shot_settings branch is causing problems. Here's the debugging steps I took:

  1. Load stock software (fe1ff169380f744d8a07c194dcae51e3264e2a39)
  2. Set cal: 0
  3. Set BFO: 11.053.0
  4. Tune A: 7040.2, LSB
  5. Tune B: 14040.25, USB
  6. Switch to A to force EEPROM save
  7. Measure clk2, clk1, clk0 pins (used nanoVNA by attaching to CH1 and measuring S21 response, since I left my oscilloscope at work)
  8. Load one_stop_settings software (b655704264d7160a1d1ee4c2d2b11386173ed324)
  9. Observe that new software shows A@...:LSB, as expected
  10. Re-measure clk2, clk1, clk0 pins
  11. Tune to A@...:LSB
  12. Re-measure clk2


Measurements from stock software:
clk2: 52.05MHz
clk1: 33.95MHz
clk0: 11.05MHz

Measurements from one_stop_settings software:
clk2: 52.05MHz
clk1: 33.95MHz
clk0: 11.05MHz
clk2 after retuning from 7040.20 to 7123.00: 52.13MHz
difference in clk2 measurements: 80kHz
difference in tuned frequencies: 82.8kHz - not an exact match, but well within my nanoVNA measurement error

Example plot of nanoVNA measurement (stock is reference/blue, one_stop_settings is active/yellow):


I wouldn't consider myself a master of RF, but if all three clocks are outputting the same frequencies in both the stock and one_stop_settings softwares, and changing the tuned value results in an equal change in the measured value, I would expect the RF side of the radio to be tuned and operate the same.

I did discover an issue with the BFO cal rendering, but it was only graphical as far as I can tell (fixed in 9a68846).

@Joel - can you describe what happened in a little more detail? Here's some specific prompts that would be helpful:
Did the radio receive anything at all? That is, could you hear normal static?
Did the screen/UI still work, in the sense that numbers were present, you could click on buttons, etc?
If the UI was working, did it display the expected settings when you updated, or were the VFO numbers all wacky?
To get back up and running, was it as easy as switching back to the PDQ branch and recalibrating, or were there extra steps you needed to take?

I finally put in an order for the remaining parts I need to get my radio built, so with any luck I'll be able to debug this myself in a few weeks :)


Reed

Reed N
 

HA! Groups.io really doesn't want email addresses, so my post above got censored a bit, it would seem.

On step 9, "A@...:LSB" should read
"A @ 7040.20 : LSB" (spaces added to avoid censorship)

On step 11, "A@...:LSB" should read
"A @ 7123.00 : LSB" (spaces added to avoid censorship)


Reed

 

Reed,

When I initially was trying out the PDQ branch the problem I was having was that upon power on conditions was, the radio would startup on some random 40 meter frequency on USB, I could hear normal static but couldn't tune anything in because of the wrong side band however, after trying the one-stop branch and reloading the PDQ branch, I no longer have the original problem. Now when I turn it on it defaults to 7.283.05 LSB which is okay. Hope this helps.

Joel
N6ALT

 

Getting your V6 up and running would no doubt make things easier for you. I have mine temporally setting on the plastic box it shipped in until I figure what I'm going to mount it in. Thanks for the work you are putting into cleaning up the code, its already much better.

Joel
N6ALT

Reed N
 

Joel,

Thanks for the reply. Something to note is that when you tune around, the frequency isn't saved all the time, since that would put a TON of write cycles on the EEPROM, which is only spec'd for 10K writes in it's lifetime. If you end up tuning to a location that you'd like to have "saved" for startup, the easiest two ways to do so are
1) switch which VFO is active (and then back)
2) switch side band mode (and then back)
Both of these operations should implicitly save the current settings to the EEPROM, and thus should come up by default at next boot.

For debugging, it would be very useful for me to understand what the difference is in behavior between the PDQ branch, and the OSS branch. Can you describe what went "wrong" with the OSS branch, vs the "normal" operation with the PDQ branch? Here's a copy of the questions from the original post:
  • Did the radio receive anything at all? That is, could you hear normal static?
  • Did the screen/UI still work, in the sense that numbers were present, you could click on buttons, etc?
  • If the UI was working, did it display the expected settings when you updated, or were the VFO numbers all wacky?
  • To get back up and running, was it as easy as switching back to the PDQ branch and recalibrating, or were there extra steps you needed to take?


Reed

Dean Souleles
 

Hi Reed -

Sent you a PM - didn't want to spam the thread for NanoVNA advice - but I'm helping with a talk on NanoVNA for our club and would like to understand the procedure for using NanoVNA to measure the SI5351 clock speeds.  I think it would be a great example in addition to demonstrating how to use it as an antenna analyzer / SWR check. 

And many thanks for all the work you are doing on the firmware!  It looks awesome.

73,

Dean
KK4DAS

Reed N
 

Dean - I haven't seen a PM in any of my inboxes, but shot you a message using the email you have on record with QRZ.com. Hopefully that puts us in touch.

All - I still plan on picking this endeavor back up, but I'm also still waiting on parts before I can complete my build, at which point I'll finally be able to test/debug the branch properly by myself :P


Reed

Reed N
 

Hey Joel,

I got enough parts that I could finally got back to this. I believe I found the source of the weirdness you saw. The issue was primarily three-fold:
  1. Per https://groups.io/g/BITX20/message/74892, the screen was rendering bad stuff when below 1MHz (1000kHz)
  2. In my code, if you set the radio to a frequency outside of the bands Ashhar had coded (3.5MHz-35MHz), it would load 0, not a safe default as I had intended. If you tuned into an AM station (1000kHz, for instance) and then turned the radio off, this would fall out of the hard coded range, triggering the bug.
  3. I wasn't loading the saved oscillator cal properly at boot, so you'd need to recal the oscillator every time (not ideal!)
When combined, these result in the display doing wonky frequency things while the VFO is WAY off from where you'd want it (0Hz isn't a popular ham band, and especially not so when uncalibrated :P).

I think I have all of that stuff sorted now, so if you're willing to give the one_stop_settings branch another go to sanity check me before I merge it into my own master, I'd appreciate it. Of course, anybody else on this thread is also welcome to give it a go :)


Reed

 

Hi Reed,

Okay, I'm using it now and all seems to be good and stable, I will continue to use it today and report back later if I run into any problems.

Joel
N6ALT