[minima] Re: Auto-calibration of the Si570 + some refactoring
- From: "Jon Lee G4TSN" <g4tsn@xxxxxxxxxxx>
- To: <minima@xxxxxxxxxxxxx>
- Date: Wed, 12 Feb 2014 08:31:09 -0000
Hi All
Over the last few days i have got the receive side working, and have to say I
am impressed with how well it works ! So far I have used the original code with
regards to frequency set and after initial adjustment of the FREQ_XTAL value I
can tune to signals on any band and they appear at same readout as my yaesu
radio so I dont think there is an issue with calibration really ?
I have used a Arduino UNO for my first proto type version and have modified the
code to use a £3 rotary encoder for tuning (sorry I don't get on with the jog
tuning idea)
the encoder I have has a push switch function if you press the tuning knob, I
have used this to change step rate of tuning which works very well.
However this does mean moving used controller pins around. I intend to keep the
original tuning pot and use that for RIT
I will post / send anyone more details if interested in the code ?
I know its early days, but I would like to see a main PCB with an amplifier
stage included for TX to bring level to say 0 or 10dBm
Thanks for such an interesting project !
73,
Jon G4TSN
----- Original Message -----
From: Mac A. Cody
To: minima@xxxxxxxxxxxxx
Sent: Wednesday, February 12, 2014 5:04 AM
Subject: [minima] Re: Auto-calibration of the Si570 + some refactoring
I forgot to comment that I think that there is too much
worry going on regarding the calibration of the Si570.
The typical unit version in use is the Si570CAC, which
provides a temperature stability of 50 ppm and a total
stability of 61.5 ppm. This is a worst-case specification,
of which most is attributable to temperature-induced drift.
At 10 MHz, this amounts to +/-615 Hz. This is pretty good,
compared to many analog VFOs. Statistically 61.5 ppm equates
to about four sigma standard deviation. Unless one is going
to place their Si570 in an oven, any efforts to provide
better calibration than that derived from the power-up
frequency specification, will be overwhelmed by temperature
drift. If one is that concerned, they would be better
served to obtain an Si570BAC, which provides a temperature
stability of 20 ppm and a total stability of 31.5 ppm. Be
prepared for the extra expense, though.
73,
Mac AE5PH
On 02/11/2014 03:02 AM, Thomas Sarlandie wrote:
Mac: Yes we 100% agree.
Steve/Farhan: We will make sure to keep some way to adjust the crystal
frequency manually.
I would love to get started writing this but I want to get my minima in
working conditions first and that means melting solder for a little while
instead of writing code ;) If someone else wants to pick this up, I would be
happy to review and comment pull requests!
73,
thomas
On Tue, Feb 11, 2014 at 12:45 AM, <farhanbox@xxxxxxxxx> wrote:
Steve, a frequency counter is not a must. You can accurately set it with
a 10 MHz receiver. It might even be far more accurate if you can beat it to WWV.
Sent from BlackBerry® on Airtel
-----Original Message-----
From: "Steve VK2SJA" <vk2sja@xxxxxxxxxxx>
Sender: minima-bounce@xxxxxxxxxxxxx
Date: Tue, 11 Feb 2014 19:07:40
To: <minima@xxxxxxxxxxxxx>
Reply-To: minima@xxxxxxxxxxxxx
Subject: [minima] Re: Auto-calibration of the Si570 + some refactoring
Some random thoughts:-
Two calibration methods exist.
1. Manually enter the start-up frequency. Software uses this value along
with additional values retrieved from the Si570 chip to calculate the
actual reference crystal value.
2. Instruct Si570 to output known frequency, say 10Mhz and adjust up and
down the software crystal reference value until the output on a frequency
counter is exactly 10Mhz.
Both methods have some Pros and Cons.
Method 1:-
You don't need a Frequency Counter
You need to know your Si570 start-up frequency (might prove awkward
finding this out without a counter - negates not needing one)
Accuracy is good. But Tomas's own results seem to show that +/- 300 Hz
might not be an unreasonable expectation.
Method 2:-
You DO require a frequency counter of some sort.
Accuracy will only be as good as the counter.
You don't need to know the Si570 start-up frequency.
It is probably reasonable to expect errors of only +/- 3 Hz after
calibration
Not every person owns a Frequency Counter. I will even allow that it is
possible that someone building a Minima may not own one.
So I would actually suggest having both methods available via a Firmware
set-up routine. Since most of the extra code would deal with changing a
value via the VFO pot. And both methods require this. A significant
portion of the code should be able to be shared between both methods.
I'm thinking something along the lines of:-
Press and hold Function button while powering up Minima to enter setup
routine. Use VFO knob to cycle through setup options. Press enter to
select the one you want. One option can be to exit setup. Something like
this:-
Setup
Calibrate 1 -> Calibrate 2 -> Other Options we haven't thought of yet ->
Quit -> Back to Calibrate 1
When you enter either Calibrate 1 or 2 the user interaction is much the
same. With one you are adjusting the crystal reference frequency up and
down until you get exactly 10Mhz on the counter. With the other you are
adjusting the value of the start-up frequency up or down until it matches
your known Si570 start-up frequency. In both cases you press the Function
button to accept and save the new value. Which returns to the top level
setup menu.
There is even a logical progression in doing both calibration routines in
order 1 and 2. While entirely non-essential Calibrate 2 could use the
calculated value produced by Calibrate 1 as its starting point. Which
would put it very close to the correct value.
Anyway just some random thoughts out loud.
73, Steve.
> Thomas,
>
> Just to be clear, what I am suggesting is that the calibration
> procedure would initially present on the display a 'common'
> start-up frequency for the Si570. As an example, the CMOS
> Si570 that is sold by KM5H
>
http://km5h.softrockradio.org/index.php?route=product/product&product_id=49
> has a start-up frequency of 56.32 MHz. If it is agreed upon that
> that start-up frequency is commonly used, then that would be the
> frequency value initially presented to the operator. If the
> Si570 actually being used has a different start-up frequency,
> then the operator can use the potentiometer to change the initial,
> value to the actual value. For example, the CMOS Si570 that I
> have has an initial start-up frequency of 10 MHz, so I would
> adjust the frequency setting displayed accordingly prior to
> pushing the function button to accept the value displayed. I
> hope this makes sense to you.
>
> 73,
>
> Mac AE5PH
>
> On 02/10/2014 12:24 PM, Thomas Sarlandie wrote:
>> Dan,
>>
>> Latest version of my code will always be available in my github
>> repository:
>> https://github.com/sarfata/radiono
>>
>> The code I was mentioning yesterday has already been merged by Farhan
>> and so you will get all my changes in the official version which is
>> available here:
>> https://github.com/afarhan/radiono
>>
>> The rest of the discussion is about what is the best way to calibrate:
>> 1 - Using factory calibration settings in the chip - but we need a
>> way for the user to find out this frequency and give it to the program
>> (maybe through a menu like what Mac suggested)
>> 2 - Starting with no calibration and a fixed output frequency
>> (10Mhz). Ask the user to adjust until it is perfectly 10mhz.
>>
>> Both method will play nicely with my changes. Nothing was lost ;)
>>
>> best,
>> thomas
>>
>>
>> On Mon, Feb 10, 2014 at 9:50 AM, Dan Reynolds <on30ng@xxxxxxxxx
>> <mailto:on30ng@xxxxxxxxx>>wrote:
>>
>> Thomas, I would still like to see your code if possible.
>>
>>
>> 73
>> Dan -- KB9JLO
>> https://sites.google.com/site/on30ng/
>>
>>
>> On Sun, Feb 9, 2014 at 8:27 PM, Thomas Sarlandie
>> <thomas@xxxxxxxxxxxxx <mailto:thomas@xxxxxxxxxxxxx>>wrote:
>>
>> Hi everyone!
>>
>> Spent some time this week-end on the Radiono software. I found
>> out earlier this week that my Si570 had a very large error
>> that grew linearly with frequency. We quickly found out that
>> each module is different and you need to use calibration
>> information that is saved in the module. The current source
>> code has Farhan's si570 calibration hardcoded in. That will
>> most likely not work for you.
>>
>> I have updated the Radiono source code to automatically get
>> the calibration information and calculate the crystal
>> frequency every time we start the program. The only
>> information that needs to be defined in the source code is the
>> default frequency programmed by the factory. In my case it was
>> 56.320 but your mileage may vary.
>>
>> There are two ways to find this frequency:
>> - Spec: Look on the marking on your Si570 (mine says
>> CAC000141) and lookup some tables online to find which
>> frequency corresponds to your marking (I cant find this table,
>> if someone has it, please share!)
>> - Experimental: just remove the Arduino and apply power to
>> the control board. Measure the frequency at the output of the
>> Si570.
>>
>> I have updated the wiki:
>> http://www.hfsignals.org/index.php/Si570
>>
>> The updated source code has been submitted to Farhan in a
>> pull-request:
>> https://github.com/afarhan/radiono/pull/4
>>
>> Full list of changes:
>>
>> Split the Si570 code in a separate class.
>>
>> In the Si570 class:
>> * Use the factory-calibrated output frequency to automatically
>> calculate the internal crystal frequency and use that instead
>> of hard coded values.
>> * During initialization detect errors talking to the Si570.
>> * Use multi-bytes i2c reads and writes when possible (ie:
>> read/write multiple bytes without re-starting a transaction).
>> Only works for read/writes in consecutive registers.
>> * Use types with explicit size where that makes sense (uint8_t
>> instead of char, uint64_t, etc)
>> * Added some debugging on the serial console through a "debug"
>> function
>>
>> In the main sketch:
>> * Show a message on the LCD if the Si570 is unreachable.
>> * Initialize the serial port for debugging
>> * Fix some compilation warnings with string litterals being
>> casted to char*
>> * Removed unused variables
>>
>>
>> And now, back to the soldering iron!
>>
>> 73,
>> thomas
>>
>>
>>
>
>
Other related posts:
