bandscope and transmit display

[Alan Hopper]

Steve, or anyone,

what is the length of continuous samples sent for the bandscope, in the rtl there is a comment that it is less than hermes but I was not sure how the comment tied up with the number. During transmit data is sent back, how far through the chain has this data traveled, has it been up converted and down converted again or is the tx iq data just sent back?

Alan M6NNB

[Steve Haynal]

Hi Alan,

Bandscope data from the Hermes-Lite is sent in blocks of 2048 16-bit words where only 12 bis of each word are used. This is 4096 bytes. The actual UDP packets break this down further into chunks of 1024 bytes, so 4 UDP pacekts for a complete contiguous block. This differs from the Hermes in the size of the block, 2048 for the Hermes-Lite, either 8192 or 16384 for the Hermes. This is because the RAM is limited in the BeMicro SDK's Cyclone IV. When John Melton enabled bandscope for the Hermes-Lite, we discussed this, and he had no problems or complaints regarding the smaller blocks. 

The Hermes-Lite shares a 12-bit bus to/from the AD9866 for TX and RX respectively. During TX, RX is seeing the data sent to the DAC on the AD9866. This data goes through the entire TX chain and then through the entire RX chain.

73,

Steve

KF7O

[Alan Hopper]

Steve,

Thanks for that, I have been playing at writing my own software to talk to the hl, (all my wspr spots from the last 3 days are through it).  I'm now working on the tx part and knowing this is a great help,

Alan M6NNB

[Steve Haynal]

Hi Alan,

That sounds great. I'd like to try it when it is ready. In case you haven't already found these resources: https://github.com/k9an/wsprcan and https://github.com/JamesP6000/WsprryPi

73,

Steve

KF7O

On Thursday, March 19, 2015 at 12:30:26 AM UTC-7, Alan Hopper wrote:

Steve,

[Alan Hopper]

Steve,

thanks for the links, you must have been reading my mind.  My wspr transmissions over the last couple of days have been directly generated in my radio code using the encoder from wsprrypi (converted to c#) and I'm now calling the k9an decoder directly, just got to do the upload part.  This all means no virtual audio and com cables which I have always disliked.  I'm not sure how far I'm going to take this code yet but I will certainly publish the wspr stuff as it could easily be incorporated into powersdr or kiss. It would be nice to come up with a standard way to plug digital mode software into sdr consoles. At the moment I have almost no gui and changing from am to usb is a recompile, I had to add lsb support this morning to listen to the local net (real software defined radio).  If it gets a bit better I'll certainly send you a copy.

Should the drive related drift remain a problem I considered correcting in software, I also very much like the idea of using ntp to correct the frequency in the long term.

Alan M6NNB

[John Williams]

Don't know if this helps, or not, Alan. Saw this a while ago to make a UI for QtRadio and then add digital decoders. Work done on Apple. Did not see any effort to port to Linux...

http://walter-moore.com/rf/category/software/qtradio/

John - AC9HY

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[irbsu...@yahoo.co.uk]

Steve,
Could the BeMicro SDRAM be used to store a larger set of bandscope samples?
I'm very interested in getting a higher resolution bandscope.
Thanks,
Andrew
G4XZL

[Steve Haynal]

Hi Alan,

Sounds great! I've always wanted to see a project do what you are doing for WSPR. This will be especially helpful when there are many receivers.

Sorry, but I haven't gotten around to disabling the second current mirror to see if that helps with the WSPR drift problem. Hopefully this week. It would be really ugly to work around this in software and hopefully there will be a hardware solution.

73,

Steve

KF7O

On Sunday, March 22, 2015 at 10:12:01 AM UTC-7, Alan Hopper wrote:

Steve,

thanks for the links, you must have been reading my mind.  My wspr transmissions over the last couple of days have been directly generated in my radio code using the encoder from wsprrypi (converted to c#) and I'm now calling the k9an decoder directly, just got to do the upload part.  This all means no virtual audio and com cables which I have always disliked.  I'm not sure how far I'm going to take this code yet but I will certainly publish the wspr stuff as it could easily be incorporated into powersdr or kiss. It would be nice to come up with a standard way to plug digital mode software into sdr consoles. At the moment I have almost no gui and changing from am to usb is a recompile, I had to add lsb support this morning to listen to the local net (real software defined radio).  If it gets a bit better I'll certainly send you a copy.

[Steve Haynal]

Hi Andrew,

The constraint on the number of contiguous bandscope samples is due to the available memory in the BeMicro SDK's Cyclone IV FPGA. If you are using a BeMicro CV, the Cyclone V on that board has more memory and can accomodate maybe 2-4x the number of contiguous samples. Also, the Cyclone V on the BeMicro CV has a hard memory controller and external RAM. With some work, one can have a much larger buffer. 

What resolution limits are you running into with the current number of bandscope samples? I would like to understand just how many samples are needed to provide a visual display that is zoomable from 48kHz to 30MHz and appears no different than current displays that rely on the full sample rate.

73,

Steve

KF7O

[irbsu...@yahoo.co.uk]

Hello Steve,
It would be nice to be able to get a 0-30MHz FFT with 250k samples (or even more) as this would allow ssb or cw signals to be resolved.
Andrew

On Tuesday, March 17, 2015 at 8:43:54 PM UTC, Alan Hopper wrote:

[Steve Haynal]

Hi Andrew,

How are you coming up with the 250K samples? Does this assume a full spectrum FFT?

Unless your goal is to have hundreds of receivers across the HF spectrum or use your HF receiver as a baseband radio, I don't think a full FFT is the way to go. The people at openhpsdr are working on this hard problem and call it DFC for direct Fourier conversion. They are using graphics processors to handle the required computations. If you think about what bandwidth is required for HF, you rarely need more than ~24 kHz of real bandwidth. A visual waterfall is nice but that is limited by the resolution of your screen (1920 wide is typical) and refresh rates (60 Hz is plenty). Given these observations, it seems best to split the processing into two paths: real bandwidth and visual bandwidth. The real bandwidth can be narrow, 24kHz or less, which makes it easy to deal with. The visual bandwidth does not need to utilize a FFT of the entire spectrum. Instead, you can mix and decimate as is traditionally done on the Hermes-Lite FPGA. Suppose you want to see 2 MHz of bandwidth centered around 21.5 MHz. You mix with 21.5 MHz and decimate with CICs down to just more than 2 MHz, then you do a FFT with a few more than 1920 bins as that is all that can be seen. These are all lower cost operations than a full FFT.  And best of all, this does not need to be done in real-time, just 60 times a second because that is all your vision will notice. You should be able to easily implement 8-16 receivers this way.

73,

Steve

KF7O

[Sid Boyce]

Hi Steve,
I should have read this next email in sequence as it addresses the benefits of DFC + PC/SBC.
73 ... Sid.

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[irbsu...@yahoo.co.uk]

Hi Steve,
No I think there is a misunderstanding, what I am meaning is a snapshot once a second or maybe a bit quicker but not streaming data. What I would like to be able to do is run a continuous 0-30MHz waterfall that could be logged to disk so that propagation and interference can be monitored as well as general noise levels. A large FFT would allow this to be zoomed right in if required.
Andrew
G4XZL

On Tuesday, March 17, 2015 at 8:43:54 PM UTC, Alan Hopper wrote:

[Steve Haynal]

Hi Andrew,

Sounds like an interesting project. You may still be better off sweeping the frequency and capturing narrow bandwidths to cover the entire 0-30MHz. I'm interested in wide bandwidth for visualization but many narrow band receivers for real data.

73,

Steve

KF7O

[Alan Hopper]

Steve,

I really like the idea of this approach and would certainly write some software to support it if you implemented it.  What I'm currently trying to do is a kludge using a mixture of bandscope and receiver data.  I guess the length of the contiguous data required comes down to the number of levels of decimation you can offer e.g. if you could do every power of 2 so we had choices of bandwidth of full,16,8,4,2,1,05 ... mhz the worst case is when you zoom to just over the nearest bandwidth (say 17mhz) you then loose half the data off the screen.  If we want a very sharp hd display it probably means a block size of 4096 to allow for this worst case, any less and zooming will not show more detail until the next level of decimation is hit.  If the steps in decimation are bigger the block size obviously has to increase for smooth zooming.  Once the bandwidth goes below about 200Khz the data rate drops below 50 frames/second and it may make sense to have continuous data here so the fft length can be tweaked to trade frequency resolution for update rate ( I want to see the modulation in a wspr signal).  It may be that half the resolution and frame rate produce something acceptable, I'll mock something up to see what is really needed.

In the ideal world there would be a number of these variable bandwidth, bandscope feeds.

I really want lots of receivers! My code will now decode as many wspr signals as there are receivers, I'd also like to use spare ones to do things like search for strong frequency reference signals to keep the frequency calibrated in the background.  I'm trying to do this now with virtual receivers on each real receiver but this has all sort of usability issues.

Alan M6NNB

[Steve Haynal]

Hi Alan,

There is now GNURadio Hermes Bandscope available:  https://github.com/Tom-McDermott/gr-hpsdr

I was going to start with that for some bandscope experiments along these lines.

Did you ever try the 2K resistor across the oscillator to reduce drift?

73,

Steve

KF7O

[Alan Hopper]

Steve,

just tried a 2.2k resistor, I'm afraid it had no effect on drift that I could measure.  I tried a very small heatsink on the ad9866 which roughly halved the drift, I'll try and fashion a bigger one.  Can the oscillator be moved away from the ad9866 or is the short connection necessary?

Alan M6NNB

[Steve Haynal]

Hi Alan,

Thanks for doing this experiment. Too bad the load on the oscillator appears to have no effect. It must be heat transfer from the AD9866 as you suggest. Yes, I think the oscillator can be moved a bit farther away in future revisions. Also, using the newer oscillator part will add to frequency/temperature stability. I have also finished the RTL (currently testing) that sets the TX gain in a way so that the second current mirror is off. All WSPR reports at 100mW now show drift of 0. I measured the currents and RX and TX currents are almost the same now so heating should not vary much between RX and TX. I imagine if you operate at 10mW you will still see drift...

73,

Steve

KF7O