Re: TinySA and phase noise. Understanding the limitations of the SI4432
#spectrum_analyzer
Here a direct comparison of the SI4432 as signal generator with the SI5351 First SI4432 at 300MHz  The phase noise is obscured by strong spurs. The SI4432 uses a fractional PLL and I did not yet spend any effort to optimize its settings Then using the same settings (except I moved accidentally to 290MHz and removed a 10dB attenuator to get the same signal levels) the SI5351  Pure phase noise is only a bit better, close in spurs are much better but the far out spurs are stronger. I guess the close in spurs of the SI4432 are also limiting the noise floor when doing small bandwidth scans, will need to investigate of there are settings in the SI4432 that can reduce these -- HBTE Files section:? /g/HBTE/filesErik, PD0EK
|
Re: TinySA and phase noise. Understanding the limitations of the SI4432
#spectrum_analyzer
On Mon, Jan 20, 2020 at 07:06 PM, jafinch78 . wrote:
1. Have you made changes that reduced the dynamic range using the Si4432 vs the Si5351?? Seems where I left off following in detail last winter... you had a lower noise floor reported.? I may be wrong and need to read through again.? If this is a correct observation, was this due to settings like decimation or something in the design??
I never did test a SI5351 as oscillator for the SI4432. Phase noise and noise floor are good enough for my applications (testing harmonics and other spectral content in home build transceiver) The decimation remark was related to spectral purity measurements using an RSP1. More decimation in the RSP1 reduces the noise floor of the RSP1
2. Reading regarding phase noise, is the 30kHz bandwidth the only issue and what limits this?? Would something like a Cross Correlation significantly improve performance (double up the spectrum analyzer modules like TSP#162 notes about 34min in and better @ 36min in)??
I am aware about the cross correlation method, it requires double hardware and long measurement time but because the RSP1 is already able to observe the phase noise I can use it to see in real time if anything I do to the tinySA improves the phase noise. But the tinySA is best at observing its own phase noise by using the 10MHz calibration output. Anything you do to clean the power supply and shield noise is directly visible Here is a picture. The purple line is when I started and after tightening the SMA connectors I got the blue line  ? -- HBTE Files section:? /g/HBTE/filesErik, PD0EK
|
Re: TinySA and phase noise. Understanding the limitations of the SI4432
#spectrum_analyzer
On Wed, Jan 1, 2020 at 06:06 AM, <erik@...> wrote:
The RSP1 was measuring with a 500Hz FFT bin size where the tinySA measured with a 30kHz resolution filter bandwidth.
The snow has fallen and is sticking around... so I'm playing catch up on the electronics and RF engineering projects from last winter post the outdoor projects last year that scope creeped into this year.?
Looks like this TinySA project has really developed into a broader range of options and is really neat reading through from a higher level detail. Looks like the Tapr-VNA has slowed down in contrast.? ?I'm starting to re-read and study more thoroughly the posts for this winter and to do some hands on work to actually make one of these TinySA's.? I'm also thinking about investing in a SB G6 so I have a 384kHz USB sound card also for wider band ultrasound recording and hoping to find a used one for a better price.? Wondering what the effect of a 384kHz sound card will be on the system also.?
For starters, I have two questions:
1. Have you made changes that reduced the dynamic range using the Si4432 vs the Si5351?? Seems where I left off following in detail last winter... you had a lower noise floor reported.? I may be wrong and need to read through again.? If this is a correct observation, was this due to settings like decimation or something in the design??
2. Reading regarding phase noise, is the 30kHz bandwidth the only issue and what limits this?? Would something like a Cross Correlation significantly improve performance (double up the spectrum analyzer modules like TSP#162 notes about 34min in and better @ 36min in)??
I'm going to have to study some more and see what effect using a GPSDO would be as I think was addressed already and maybe would be better for the calibration and I'm guessing thermal noise characterization to set values in the software.?
Wondering also what improvements will be like enclosing the modules better as I have the mini-lathe vertical slide so I can machine, like a horizontal mill, enclosures eventually.?
Thanks for sharing, excellent info!
|
I know that the number of bits depend on the settings and that the 12b is a "optimistic"
value but had no idea about this. Will have to keep that in mind. Thanks.
On Sun, 19 Jan 2020 at 19:58, Dave VE3LHO < dave@...> wrote:
On Sat, Jan 18, 2020 at 09:28 PM, Jerry Gaffke wrote:
Indeed, the $2 Blue Pill has two 12bit A/D's, good to 1 msps, up to 16 channels.??
Unfortunately, the raw specs can be misleading. The issue, typically, is noise which causes the lower bits of the ADC result to be garbage.
There is a figure of merit for ADCs called Effective Number of Bits (ENOB). ENOB is basically how many bits you can rely on to actually represent the signal at the input to the ADC. Some people have measured ENOB for Blue Pills and found that there are fewer "effective" bits than on a typical 8b Atmel Arduino board. 7? or 8 as I recall where I think the Arduino boards being measured were 8 or 9.
The speculation is that the culprit on the Blue Pill boards is the poor layout and 2 layer board. Apparently, the original LeafLabs Maple boards which used the same ST32 micro had better ENOB.
|
After 20 years in the IT industry I was starting to feel a bit like a greybeard but compared to you guys
I kind of feel like a youngster again :)
"all thumbs" is the perfect way to describe it.
On Sun, 19 Jan 2020 at 20:01, Jerry Gaffke via Groups.Io <jgaffke= [email protected]> wrote: I wasn't directly involved in either processor design, but in the late 70's
I worked at a company called Ramtek (long since failed) where they?
had a PAL to flip the memory map (all 64kbytes of it) when an interrupt came in
to switch the processor over from user state to system state.
And in the 80's, a firm called Metheus where they had two 68000 processors
for system and user state, one was always idle and waiting for the flip.
This was before the 68020 came out.
In '89 I spent a year in Japan, part of my job was writing DMA device drivers
to lock down part of main memory and then continuously shovel out a ring buffer
of data to an IO port as fast as possible.? One was on a Sony News Unix box,
all the manuals in Japanese, but fortunately all the technical terms
were English words spelled out phonetically in katakana.
And yes, each bug fix meant an hour or so of compiling the kernel.
I often dreamed of building my own computer from college on,
but never successfully acted on it as Erik did.
In the 90's, all the cheap engineering tools moved to MSWindows, unfortunately.
I was all thumbs until I could install a fake unix command line prompt,
similar to cygwin, percentshell, or minGW.? Tried my best not to muddy my brain?
with that MSWin crap, thankfully there was always somebody to ask when I had
to edit a registry or configure a network connection.
Jerry, KE7ER
|
Dave,
Good point, hadn't known.
Thanks for describing the poor A/D performance of the typical Blue Pill board.
I like the thought of a tinySA board with just an SPI port, make it processor agnostic.
Add RF filtering to the SPI lines.
If you ever need an A/D, put it down as an SPI peripheral.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Sun, Jan 19, 2020 at 10:58 AM, Dave VE3LHO wrote:
Some people have measured ENOB for Blue Pills and found that there are fewer "effective" bits than on a typical 8b Atmel Arduino board. 7? or 8 as I recall where I think the Arduino boards being measured were 8 or 9.
The speculation is that the culprit on the Blue Pill boards is the poor layout and 2 layer board. Apparently, the original LeafLabs Maple boards which used the same ST32 micro had better ENOB.
|
I wasn't directly involved in either processor design, but in the late 70's
I worked at a company called Ramtek (long since failed) where they?
had a PAL to flip the memory map (all 64kbytes of it) when an interrupt came in
to switch the processor over from user state to system state.
And in the 80's, a firm called Metheus where they had two 68000 processors
for system and user state, one was always idle and waiting for the flip.
This was before the 68020 came out.
In '89 I spent a year in Japan, part of my job was writing DMA device drivers
to lock down part of main memory and then continuously shovel out a ring buffer
of data to an IO port as fast as possible.? One was on a Sony News Unix box,
all the manuals in Japanese, but fortunately all the technical terms
were English words spelled out phonetically in katakana.
And yes, each bug fix meant an hour or so of compiling the kernel.
I often dreamed of building my own computer from college on,
but never successfully acted on it as Erik did.
In the 90's, all the cheap engineering tools moved to MSWindows, unfortunately.
I was all thumbs until I could install a fake unix command line prompt,
similar to cygwin, percentshell, or minGW.? Tried my best not to muddy my brain?
with that MSWin crap, thankfully there was always somebody to ask when I had
to edit a registry or configure a network connection.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Sun, Jan 19, 2020 at 09:57 AM, Dragan Milivojevic wrote:
You win the internet for today ;)
Totally unrelated to the topic but: with that kind of background how do you bare using Windows?
Evrytime that I'm forced to use it (which is not often thankfully) I feel like if someone tied one of my hands.
Hide quoted text
?
On Sun, 19 Jan 2020 at 18:44, < erik@...> wrote: I was talking about a 128kByte program for a 68000 compiled on VAX/VMS downloaded through a 9600 B/s connection. The downloading took most of the time
Maybe this shows my age?
And yes, I did build all the HW for my own 68000 System 5 Unix system including a modified full swap kernel as I could not afford the MMU
|
On Sat, Jan 18, 2020 at 09:28 PM, Jerry Gaffke wrote:
Indeed, the $2 Blue Pill has two 12bit A/D's, good to 1 msps, up to 16 channels.??
Unfortunately, the raw specs can be misleading. The issue, typically, is noise which causes the lower bits of the ADC result to be garbage. There is a figure of merit for ADCs called Effective Number of Bits (ENOB). ENOB is basically how many bits you can rely on to actually represent the signal at the input to the ADC. Some people have measured ENOB for Blue Pills and found that there are fewer "effective" bits than on a typical 8b Atmel Arduino board. 7? or 8 as I recall where I think the Arduino boards being measured were 8 or 9. The speculation is that the culprit on the Blue Pill boards is the poor layout and 2 layer board. Apparently, the original LeafLabs Maple boards which used the same ST32 micro had better ENOB. This is something to be aware of for almost all ADCs: the ENOB may be less than the actual number of bits even with the best board layout. This is due to noise in the chip itself. Standalone ADCs are (much) better. ADCs integrated into a processor SoC will have a worse ENOB than the "equivalent" standalone ADC and in no case will their ENOB match the published max. The SoC has its own sources of noise and on die "layout" issues. There are techniques to improve ENOB including turning off other functions (clocks) in the chip during sampling, and repeated sampling and averaging but be aware that published ENOB numbers may use those techniques (read: you will get a worse ENOB, unless you use them as well). Of course, since most of us are buying the cheapest available clones from random suppliers with unknown quality the published numbers may be better than we can expect? :-)
A 72mhz 32bit ARM processor, 64kbytes of flash, 20kbytes of SRAM, lots of IO pins
Runs on 3.3v, so no need for level shifters talking to an Si4432.
Totally blows the doors off a Nano in every way.
... stuff deleted ..
Now on the RPi, the (nonexistant) A/D is definitely not up to the Nano spec.?
Though I don't see where the tinySA needs an A/D.
True. I think this is just a useful thing to be aware of in general. To balance off as a "cost" against the $2 price of the Blue Pills when looking at other projects.
And would be easy to add an A/D as a peripheral if it is needed.
Jerry, KE7ER
On Sat, Jan 18, 2020 at 04:31 PM, Dragan Milivojevic wrote:
If memory serves me right more bits, more channels and sampling speed up to 2M so not sure what you mean?
|
Just checked with one of my STLink clones that I did not convert to BMP wondering how did I miss the serial port.
Anyway it seems that virtual serial is not available with STLink 2 only with 2.1.
Bummer.
On Sun, 19 Jan 2020 at 19:13, < erik@...> wrote: May have made a wrong comment, no need to do something in the ini file, should work out of the box.
The ini file change is needed when you want to use SerialUSB with Blue Pill.
--
HBTE Files section:?/g/HBTE/files
Erik, PD0EK
|
NXP app note with diagram and explanation is here:
toggle quoted message
Show quoted text
On Sat, Jan 18, 2020 at 12:42 PM, Joerg ex-DB2OO wrote:
I used an I2C level shifter module with 4 level shifters, which I purchased on eBay (approx EUR 1.95).
This does a conversion between the low and the high voltage in a bi-direction way:
For the 5th signal I simply used a resistor voltage divider with 560Ohm connected to the Nano output (5V) and 1kOhm connected to ground.
The midlle of the divider is connected to the SI4432 input.
Generally you can use these voltage dividers for all outputs of the Nano.
This will leave just one signal, that needs a 3.3V --> 5V conversion, which requires e.g. a level converter as shown above. Not using an up-level converter might work, but the input level at the 5V Arduino will be out of spec.
There are other ways for level conversion like shown here:?.
Overall my prototype TinySA with an Arduino Nano looks like this:
--
Joerg, ex-DB2OO
|
May have made a wrong comment, no need to do something in the ini file, should work out of the box. The ini file change is needed when you want to use SerialUSB with Blue Pill. -- HBTE Files section:? /g/HBTE/filesErik, PD0EK
|
I had no idea that you could do that, will have to look it up.
Thanks
Dragan,
In platformIO you can set your ini file to include a serial console over the STLink
|
You win the internet for today ;)
Totally unrelated to the topic but: with that kind of background how do you bare using Windows? Evrytime that I'm forced to use it (which is not often thankfully) I feel like if someone tied one of my hands.
On Sun, 19 Jan 2020 at 18:44, < erik@...> wrote: I was talking about a 128kByte program for a 68000 compiled on VAX/VMS downloaded through a 9600 B/s connection. The downloading took most of the time
Maybe this shows my age?
And yes, I did build all the HW for my own 68000 System 5 Unix system including a modified full swap kernel as I could not afford the MMU
|
Re: Tuning the frequency of the tinySA calibration output
#tinysa
On Sun, Jan 19, 2020 at 07:17 AM, K9HZ wrote:
Whats then really needed is a good separate/calibrated frequency counter,
That is what I did as first step. /g/HBTE/message/691Although the NEO-7M may have some jitter when doing 10MHz the frequency counter does not mind and with its TXCO it is VERY stable and VERY cheap ? -- HBTE Files section:? /g/HBTE/filesErik, PD0EK
|
On Sun, Jan 19, 2020 at 08:03 AM, Dragan Milivojevic wrote:
If you have some free time try the BMP, the "integrated" serial console
?is quite convenient, one cable less to get tangled
Dragan, In platformIO you can set your ini file to include a serial console over the STLink ? -- HBTE Files section:? /g/HBTE/filesErik, PD0EK
|
I was talking about a 128kByte program for a 68000 compiled on VAX/VMS downloaded through a 9600 B/s connection. The downloading took most of the time Maybe this shows my age? And yes, I did build all the HW for my own 68000 System 5 Unix system including a modified full swap kernel as I could not afford the MMU -- HBTE Files section:? /g/HBTE/filesErik, PD0EK
|
Wow, 3 hours to compile a C application?
C should be as fast as anything else to compile.
An interpreter like python skips the compile, but then run times are much slower.
You either had a terribly bloated IDE for the C compile
or you were compiling a unix kernel on an 80386.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Sun, Jan 19, 2020 at 06:55 AM, <erik@...> wrote:
When I started with programming C I had one application where I had to wait 3 hours before the code was compiled and downloaded on the real time target.
|
The RPi-Zero is nearly the size of a Nano, and with the monitor powered down that might well create about as much noise.? Actually I'm rather surprised Eric is getting such good results with his Arduino so close to the RF modules. Jeorge successfully used some open drain level shifters on his tinySA to level shift between 3.3v and 5.0v: ? ? /g/HBTE/message/738Those level shifters are aimed primarily at i2c, pin capacitance will restrict how fast the pullup resistors can bring any of those signals high.? So edge rates are probably a couple orders of magnitude slower than a straight up SPI bus could do. SPI uses standard totem-pole drivers, not the bi-directional open drain signalling used by i2c. Since it can be so slow, we could add filters to the four SPI lines and kill anything below a few hundred khz.? And have the RPi a few meters away in a metal box, the HDMI monitor powered down when taking a measurement if necessary. Alternately, put the tinySA and the DUT in a metal box or wire mesh cage. Jerry, KE7ER
On Sun, Jan 19, 2020 at 08:03 AM, Alan Jones wrote:
Jerry,
You make a good point about being able to do software development right on the RPi.
In your opinion, what are the RFI concerns about using the Pi-Zero?
?
Al, N8WQ
|
Re: Tuning the frequency of the tinySA calibration output
#tinysa
It's a hobby, so if it's fun I suppose that's fine.
But I'd rather just drive the 30mhz reference from an accurate RF source when needed.
Could leave the crystal in place, just have an SMA in parallel with it.
I've got a NEO-7M ordered, if only to see how clean the output of an Si5351 is?
when driven from the dirty 24mhz output of the NEO-7M.
My guess is pretty clean, and that this combination will be useful all by itself on the bench.
If the 24mhz doesn't work well, I could discipline in firmware using the 1pps from the NEO-7M.
And if the GPS system proves too flaky, maybe I'll blow my beer budget on one of these:?
? ??
Of course, I'll need to build a spectrum analyzer up before I'll know how clean.
?
I have a whole pile of toys on order now, it's become very cheap to play with all this stuff.
But first I need to pass a final inspection on this house before the county gives up on me.
Yet another hobby, as straw bale and mud is not a quick way to build a house.
Jerry, KE7ER? ? Flora OR
toggle quoted message
Show quoted text
On Sun, Jan 19, 2020 at 06:29 AM, <erik@...> wrote:
Through register 0x09 of the SI4432 you can select capacitance from a capacitor bank??parallel?to the crystal?to change the frequency of the crystal oscillator.
In practice you need to take a number of steps.
|
Only thing that is left now is to invent a cheap teleport machine and send it to Serbia ;)
If I could only find it for $5, locally it is around €25, on ebay and aliexpress ~$20 Rpi with wireless would be ideal for over the net SDR (thinking about setting up a satellite dish for Oscar 100).
But I'd much prefer a $5 RPi-Zero.
? ??/g/HBTE/message/596
Can do software development right on the RPi, has 3.3v IO pins that speak SPI,
and can drive anything from a $2 16x2 LCD to a 30" 1080p HDMI monitor.
?
|
jafinch78 .