Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Si5351 correction question
|
I have finally got my "Franken" uBitx to the point where it is receiving
signals; at least from my HP 8642A signal generator. But, there is something strange going on, and I am wondering if anyone else has seen the same strangeness. When I originally ran the si5351 calibration program, everything looked great and I have up with a correction number of 15380. The 10 MHz was measured by my HP 53131A counter referenced to a GPSDO. Fast forward to a little more testing, and I discovered signals I had been receiving were no longer where they once were. Running the calibration program again, with the same Adafruit Si5351 board, I arrived at a correction number of 14210. So my question is: has anyone else seen the same Si5351 use different correction factors to generate the same output frequency? Really scratching my head over this one. 73 - Mark N1VQW |
|
Hi,
toggle quoted message
Show quoted text
Did you run in upper sideband and the other in lower sideband? I think that would make a difference. The instructions I have specify doing that calibration with the radio in upper sideband. 73, Bill KU8H On 11/02/2018 05:45 PM, Mark Pilant wrote:
I have finally got my "Franken" uBitx to the point where it is receiving --
bark less - wag more |
|
Hi Bill.
Did you run in upper sideband and the other in lower sideband?This is a bare Si5351 board being controlled by an Arduino. This is the environment in which the calibration sketch expects to execute. If I set the correction constant, I get the correct frequency at the Si5351 CLK2 for the ubitx. I'm just surprised I had to use two different values. I wonder if it could be related to how long the board had been powered on. 73 - Mark N1VQW |
|
Mark M
What firmware are you running??
Mine seems to be OK on xmit but several hundred Hz off on rcv. I'm thinking it might be the constants used in the firmware for the USB & LSB offsets. They're used by the firmware to calculate the freqs for CLK1 for a given dial freq. The BFO freq (CLK0) also will affect the actual tuned freq. AFAIK, the only way to change those CLK1 constants is editing the firmware source. CLK2 is the only one used on xmit and then it should be the dial freq +- 800 Hz depending on sideband selection. At least that's how I understand it from wading thru the firmware source (I'm running the CEC v1.11 firmware). Mine also seems to change slightly as it warms up and it also does not seem to track linearly...if I get it spot on for, say, 14 Mhz, it's off at 7 Mhz and vice versa. |
|
Mark wrote:
toggle quoted message
Show quoted text
> CLK2 is the only one used on xmit and then it should be the dial freq +- 800 Hz depending on sideband selection. When transmitting, the display should show the frequency of the carrier in the case of CW, and should show the frequency of the suppressed carrier in the case of SSB. If your firmware does otherwise, that's a bug. The only funny stuff is during receive of CW, the receiver must tune to one side of the incoming carrier so you can hear a beat note between that signal and your BFO. When transmitting SSB, all three clocks are used in double conversion,? the process is the same as during receive except reversed. All three clocks remain the same when switching from receive to SSB transmit. When transmitting CW, clk0 and clk1 are shut down, the mixer at D1,D2 is unbalanced, and clk2 is set to the operating frequency. I'd recommend the?algorithm of post???/g/BITX20/message/54501?for calibration. Tune the rig following the algorithm of post??/g/BITX20/message/44278 The funny offset for CW receive is not included in that tuning algorithm, an exercise for the reader. I have no idea what the various firmware releases are doing these days except that none of them seem to be doing it right. Jerry, KE7ER On Fri, Nov 2, 2018 at 10:11 PM, Mark M wrote: What firmware are you running?? |
|
Hi Mark.
What firmware are you running?None. The calibration sketch is here: This sketch simply programs the Si5351 as an oscillator, no USB, LSB, offset, etc. Hi Jerry. I'd recommend the algorithm of post /g/BITX20/message/54501I'm eventually going to be doing something similar to what was mentioned in your post. My main puzzler is why, given the same Si5351 and Arduino boards, did the correction number need to change to get the correct output frequency? 73 - Mark N1VQW |
|
I have not heard of others in the forum voice concern about the si5351 calibration changing.?
toggle quoted message
Show quoted text
Unless you are using different firmware or there is an error in the firmware, that sounds like the 25mhz crystal reference oscillator at the si5351 has changed a bit. If you have a good second rig that can receive 25mhz, perhaps bring a short antenna from it close to your uBitx and listen to the 25mhz oscillator, see if you can hear it move, perhaps when blowing hot air on the si5351 board. Assuming your firmware is using the si5351bx routines that Farhan's original release was using, then the correction factor says how many hertz off from 875mhz the vco internal to the si5351 is. The clock output frequencies and the rig operating? frequencies will be moved by a factor? exactly proportional to to that correction factor, assuming your firmware is written correctly. For example, you report two different correction factors of 15380 and 14210. So in the first case, the vco was at 875.015380 hz, and in the second case at 875.014210 hz, and the vco moved by 15380-14210 = 1170 hz, slightly more than a 1ppm difference. That could be attributed to temperature or power supply differences around the si5351 and crystal. A rig operating at 3.5mhz would have moved by? ?3.5mhz * (1170/875000000) = 4.68hz If the rig was operating at 28mhz, it would have moved by 28mhz * (1170/875000000)?= 37.44 hz.? Unless you are operating in one of the narrow band digital modes, those shifts are not of much consequence. If you are operating in a narrow band digital mode in a varying temperature environment, you may need a more stable reference than the 10 cent? 25mhz crystal supplied with your si5351 board. There are si5351 boards out there with a TCXO (temperature compensated crystal oscillator)? from QRPLabs and Etherkit.? ?The QRPLabs board can be GPS disciplined. Or I suppose you could look into rubidium oscillators.? ?;-)? I don't know if you are experiencing temperature or voltage changes around the si5351, or exactly how much the frequency would shift if you did. It could be that you have a more sensitive crystal than most, you might experiment with swapping it out.? Better yet, get a different si5351 board.? Preferably one with a TCXO. You might try cleaning the area around the si5351 and 25mhz crystal with alcohol. Jerry, KE7ER ? ? On Sat, Nov 3, 2018 at 07:04 AM, Mark Pilant wrote:
My main puzzler is why, given the same Si5351 and Arduino boards, did the correction |
|
Hi Jerry.
I have not heard of others in the forum voice concern about the si5351 calibrationI have not as well, but I wanted to check to see if my symptoms jogged anyone's memory. :-) Assuming your firmware is using the si5351bx routines that Farhan's original releaseI'm not sure if it is; I haven't actually checked. The sketch I'm using to test the Si5351 is in the Etherkit (NT7S) GitHub repository. I might have to check out the 25 MHz oscillator. I have an HP Modulation Analyzer which should do the trick. (It also uses my GPSDO as a reference.) I do have an Efratom rubidium standard, but find my GPSDO (HP Z3816A & Spectracom 8140) more convenient :-) :-) 73 - Mark N1VQW |
|
Hi Bill.
When I replied with a suggestion he told me he is not using a Bitx40 nor uBitxTrue at the moment. I'm actually using a Mega2560 to control the Si5351 board with a 3.5" TFT LCD interface. The software is based on the VU2SPF and VE1BWV sketch, with the appropriate changes to run the display (which uses an HX8357D chip). I opted to use the simpler si5351 sketch to eliminate as many variables as possible to make sure the Si5351 board is operating as it should. Here is a link to my work as of a couple of months ago: I need to update it after picking it up again a week or two ago. (Too many irons in the fire :-) 73 - Mark N1VQW |
|
The etherkit library is totally different than the si5351bx routines used on the uBitx.
toggle quoted message
Show quoted text
So my discussion of the correction factor may or may not pertain. Good luck. On Sat, Nov 3, 2018 at 09:46 AM, Mark Pilant wrote: Hi Jerry. |
|
Vince Vielhaber
I looked at your project and see you're using the adafruit si5351 board. There was an issue some time ago and recalling from a hazy memory it had something to do with crystal loading and the si5351 settings for the crystal. This caused the si5351 to be slightly off frequency. Jerry may remember more about it as I believe he addressed it in the si5351bx routines. I know it affected the Raduino, I'm just guessing the Adafruit is using the same or very similar crystal due to cost and availability.
toggle quoted message
Show quoted text
Vince. On 11/03/2018 12:52 PM, Mark Pilant wrote:
Hi Bill.When I replied with a suggestion he told me he is not using a Bitx40nor uBitxnor a raduino nor any of the Bitx or uBitx software. -shrug-True at the moment. I'm actually using a Mega2560 to control the Si5351 --
K8ZW |
|
Hi erry,
toggle quoted message
Show quoted text
My comments were in a completely different universe :) I assumed being posted here it was something it is not. While we all know about "assume" it isn't unreasonavle to expect questions posted here to be about the Bitx machines. Moving on... 73, Bill KU8H On 11/03/2018 12:53 PM, Jerry Gaffke via Groups.Io wrote:
The etherkit library is totally different than the si5351bx routines --
bark less - wag more |
|
Vince says:
toggle quoted message
Show quoted text
> crystal loading and the si5351 settings for the crystal. This caused the si5351 to be slightly off frequency. This applies to pretty much all si5351 builds, so may actually be pertinent to the forum. The 25mhz crystals typically available are tuned on the assumption that there will be maybe 18pF of capacitance in parallel with the crystal.? (It's in the datasheet for your particular crystal.) The si5351 allows you to program a parallel capacitance across the crystal of 6, 8 or 10pF. There might be another pF or so due to traces, but we're typically well short of that 18pF So our reference oscillator might be a khz above the expected 25mhz. This is corrected by, wait for it ....? the correction factor. As described in a previous post. I did a quick check. The Etherkit correction factor is in parts per billion, not in hz variance of the vco. So Mark's change was 1.170 ppm, not 1170/875000000 * 1e6 = 1.337ppm So his error was 12.5% less than I had previously calculated on the assumption he was using the si5351bx routines. In the si5351bx routines as I wrote them, you simply the value of si5351bx_vcoa Farhan has added a level of indirection to this, his correction factor get's added to the 875000000 default for si5351bx_vcoa. Jerry, KE7ER On Sat, Nov 3, 2018 at 11:13 AM, Vince Vielhaber wrote: I looked at your project and see you're using the adafruit si5351 board. There was an issue some time ago and recalling from a hazy memory it had something to do with crystal loading and the si5351 settings for the crystal. This caused the si5351 to be slightly off frequency. Jerry may remember more about it as I believe he addressed it in the si5351bx routines. I know it affected the Raduino, I'm just guessing the Adafruit is using the same or very similar crystal due to cost and availability. |
|
Somebody asking a non *Bitx* question here should give a full description
toggle quoted message
Show quoted text
of what they have and they are doing.? (This applies to those asking a *Bitx* question as well.) And they should make sure it relates to *Bitx* products. Some might consider this one borderline, but I think it's informative for *Bitx* users. The original Raduino firmware for the Bitx40 used the Etherkit library. Jerry On Sat, Nov 3, 2018 at 11:56 AM, Bill Cromwell wrote:
My comments were in a completely different universe :) I assumed being posted here it was something it is not. While we all know about "assume" it isn't unreasonavle to expect questions posted here to be about the Bitx machines. Moving on... |
|
Should read:
toggle quoted message
Show quoted text
"In the si5351bx routines as I wrote them, you simply adjust the value of si5351bx_vcoa" That's how I do it in my own code. But in the example code scrap of post 54501, I hacked it to use the indirect calibration offset, since that's what everybody else seems to be doing here. And managed to misspell "calibration: < calibration = calibrtion + 10*enc_read(); > calibration = calibration + 10*enc_read(); Could be other minor bugs like that, but the method presented is correct. On Sat, Nov 3, 2018 at 12:01 PM, Jerry Gaffke wrote:
In the si5351bx routines as I wrote them, you simply the value of si5351bx_vcoa |
|
FWIW when I operate 20 meter FT8 with my uBitx the WSJT-X waterfall display clearly shows about a 200 Hz upward drift for the first 10 to 12 minutes after I power it on. I don't know how that would translate to the drift in the 25 MHz crystal reference.
toggle quoted message
Show quoted text
Mike K5ESS -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mark Pilant Sent: Friday, November 2, 2018 4:46 PM To: [email protected] Subject: [BITX20] Si5351 correction question I have finally got my "Franken" uBitx to the point where it is receiving signals; at least from my HP 8642A signal generator. But, there is something strange going on, and I am wondering if anyone else has seen the same strangeness. When I originally ran the si5351 calibration program, everything looked great and I have up with a correction number of 15380. The 10 MHz was measured by my HP 53131A counter referenced to a GPSDO. Fast forward to a little more testing, and I discovered signals I had been receiving were no longer where they once were. Running the calibration program again, with the same Adafruit Si5351 board, I arrived at a correction number of 14210. So my question is: has anyone else seen the same Si5351 use different correction factors to generate the same output frequency? Really scratching my head over this one. 73 - Mark N1VQW |
|
All three local oscillators into the uBitx that determine the operating frequency
toggle quoted message
Show quoted text
are sourced by the si5351. And the clocks out of the si5351 are strict ratios of the 25mhz reference frequency So any error in the 25mhz reference clock will be exactly proportional to the error in your displayed operating frequency. Assuming the firmware was done correctly. Example: When tuning to the rig to 14.0mhz, you find that you are receiving a signal at 14.001 mhz. Then the 25mhz reference must be at 25.0*14.001/14 = 25.001786 mhz? That's a 1e6 * 200hz/14000000hz = 14.3 ppm difference.? ?(where 1e6=1,000,000, to convert a ratio to parts-per-million) Makes me wonder how much of a temperature change is involved here. Mark had previously reported a roughly 1ppm drift in his Adafruit si5351 board.? Jerry On Sat, Nov 3, 2018 at 04:33 PM, K5ESS wrote: FWIW when I operate 20 meter FT8 with my uBitx the WSJT-X waterfall display clearly shows about a 200 Hz upward drift for the first 10 to 12 minutes after I power it on. I don't know how that would translate to the drift in the 25 MHz crystal reference. |
|
Hi Jerry.
Makes me wonder how much of a temperature change is involved here.This may be on target. I did a little more testing this morning and a different correction number was needed to get the correct frequency. Actually between the two from yesterday. Two temperature factors may come into play. First, my "shop" is in the basement and we had a fairly cool night. Second, everything had been powered off overnight, so it was all from a cold start. I just wanted to close the loop on this one. 73 - Mark N1VQW |
|
Here's a randomly chosen datasheet for a 25mhz crystal out of Mouser:
toggle quoted message
Show quoted text
? ??https://www.mouser.com/datasheet/2/96/008-0308-0-1160929.pdf On page 3, it say the "Frequency Stability Tolerance" is +/- 50ppm over an operating temperature range of -20C to +70C. That's 50ppm/(20+70) = 0.555 ppm per degree C, or 0.555*9/5 = 1.0 ppm per degree F. (I'm assuming frequency vs temperature is a linear relationship, should be close to correct.) Mark was seeing his correction factor change by 1170 ppb, or 1.170ppm. Using this crystal, we might see such a frequency shift when the temperature changes by just over 1 degree Fahrenheit. Mike said he saw 200hz of drift during warm-up while operating at 14mhz. That's? ?1e6 * 200/14000000 = 14.3 ppm. This particular crystal from Mouser could shift that much if the temperature inside the rig changed by 14 degrees Fahrenheit (or 8 Centigrade). Other (cheaper?) crystals can be worse in this respect. How the crystal oscillator circuit inside the si5351 responds to temperature is also a factor, this could add or subtract from that crystal frequency shift. Anyways, use a TCXO controlled si5351 board if worried about stability. Lots of the TCXO's available are digitally controlled and make adjustments in discrete jumps of several hz, you want a good old fashoned analog TCXO for radio stuff. A cheap solution might be to attach a temperature sensor out near the crystal and si5351. The processor reads the temperature sensor and adjusts how it programs the si5351 accordingly. The si5351 allows those adjustments to be made in increments of around 0.01ppm, or 0.14 hz at 20m. Some of the other SiLabs parts (si5338, si5341, si570, ...) allow these increments to be at least an order of magnitude smaller, to where there would be no perceivable jump.? Jerry, KE7ER On Sun, Nov 4, 2018 at 09:05 AM, Mark Pilant wrote:
Hi Jerry. |
to navigate to use esc to dismiss