myriadrf / rasdr Goto Github PK

Open hardware files are provided, but I'm not sure what sort of facility I should be looking for to actually create them and how much it would cost. Would a big university have the equipment to manufacture this?

On systems where the fonts have been enlarged to Medium (125%) or Large (150%) the rendering of the RASDRproc window is incorrect.

Currently, the workaround is to set the font size in Control Panel->Display to Small (100%) and logout/login to your session before running RASDRproc.

1. Update existing DigiRED Development Kit documentation to refer to RASDR2 specifically
   • updated VID/PID, screenshots and procedures
   • add firmware loading, currently roughed-in at CyControl host software
2. Add RASDRviewer usage

On Mon, Aug 15, 2016 at 10:39 PM Bogdan Vacaliuc [email protected] wrote:

Hi Nathan,

Ok. I know that I have not done a good job describing what it is that I'm building for RASDR3 and I did not submit a paper for the annual conference, and so was not entitled to present. There is no difference between RASDR2 and RASDR3 in terms of function. This is what makes a RASDR3:

DigiRed board:

1. change size from 2"x2" to 3" x 5" to match context engineering 3008-series cases
2. remove unused components in the TX side {FX3, connector, power supplies}
3. move 20-pin GPIO header position, expand to 40-pin (some pins not connected) to match Raspberry-PI HAT electromechanical specification
4. move/change USB connector to edge of board and make it full size USB3.0 B type
5. move SMA refclk connector to edge of board near USB connector
6. add power connector, jumper and use correct circuit to enable self-powered operation of the device
7. move/change LEDs to edge of the board
8. move/change PROG/RUN to a switch on the edge of the board

MyriadRF board:
no changes from published RASDR2 adjustments

Case:
Context Engineering 3008F-5N ($17/qty=1) with custom stamping for CW/RX SMA ports on one side, and REFCLK, USB, POWER, LED, PROG/RUN switch on the other side.

With these modifications, there is no need for any inside wiring. While I am at it, why don't I go ahead and describe the assembly process:

1. mount MyriadRF board on to DigiRed board using mounting hardware (provided in kit)
2. fit the RF shield (provided in kit) onto the MyriadRF board
3. slide DigiRed+MyriadRF board into (3rd slot) on Case bottom (labeled)
4. fit top of case (labeled) into groove on top of bottom case
5. attach sticker (provided in kit) onto the flanged end bracket with two holes, and use an x-acto knife to cut out the sticker from the hole (*)
6. fit flanged end bracket onto case with the two SMA connectors poking through the end bracket and secure with 4 screws on corners
7. ensure DigiRed+MyriadRF board is pressed fully forward into the box, and fit SMA washer and nut onto outside of the CW and RX barrels and tighten down
8. attach sticker (provided in kit) onto the flanged end bracket with many holes, and use an x-acto knife to cut out the holes(*)
9. fit flanged end bracket onto end of case, making sure to line up the REFCLK SMA and PROG/RUN switch and secure with 4 screws on corners
10. fit SMA washer and nut onto outside of the REFCLK barrel and tighten down
11. attach sticker (provided in kit) onto the top of the case

At this point, electrical and functional testing may begin.

Bent Pedersen sent a message using the contact form at
http://www.radio-astronomy.org/contact/Technical-Queries.

Hi Folks,
Have downloaded the viewer, thinking it could be a useful software to follow
a RTL dongle 'listening' on 1420 MHz.
But after a few hours of experimenting, it stood clear that the Dongle cannot
be used as receiver in connection with RASDR - correct ?
Best regards,
Bent, OZ6BP.

User would like to use the astronomy software with hardware other than RASDR. There are several challenges to this:

1. the UI is highly integrated with the Lime Microsystems C library distribution that preceded the LMS7002M software release.
2. normalization calculations are determined by the response of the ADC in the LMS6002D device

There have been discussions on a way forward, and some of them include using SoapySDR. To accomplish this, an LMS6002D device support for SoapySDR would need to be created, then SoapyRemote would be the interface that the rasdr software would interface with.

In #11, we provided a basic integration with Jim Sky's Radio Sky Spectrograph. There is a desire to extend the spectrum output to include more frequency bins and to use full precision. Essentially to produce rtl-power-compatible output files.

Here is the relevant discussion:

On Thu, Aug 4, 2016 at 7:16 AM, Bogdan Vacaliuc [email protected] wrote:

re: the connection string for the extended format output. How do you want to do this? Keep the same 4 key,value pairs as RSS and add more key, value using the same parsing format? Can we use keys with more than just one character in the extensions if so? Switch to .json?

re: the format for the scans. should we use a binary version of the rtl-power output? How about this variation:

timestamp (IEEE-754 8-byte double)
hz_low (IEEE-754 4-byte float)
hz_high (IEEE-754 4-byte float)
hz_step (IEEE-754 4-byte float)
samples (4-byte integer)
db-values (IEEE-754 4-byte float) * CHANNELS (as given in the header)

I dont think we need the end code marker. I would have preferred to have a stateless stream, but the method of disconnecting when offset/center frequency and channels are changed seems to work very well.

On Thu, Aug 4, 2016 at 11:18 PM, Tony Bigbee [email protected] wrote:

Re: key value pairs. I suggest extending the key to a full variable name and just separating by space with the value and keeping the pipe delimiters. I would also be fine with JSON --it's easy to parse in any language.

Ditching the end code marker is perfectly fine with me. I can easily dynamically compute the scan boundaries.

Here is the detail on the "Extended RSS" implementation simiar to Jim's spec for RSS:

The RASDRproc program acts as a TCP server and listens for a connection on the port defined by the 'Setup RSS Output' as described here. Configure your program to connect to this IP:PORT combination. Upon a connection, RASDRproc accepts the connection and sends an 1024-byte ASCII string as a response. The response will be key value combinations separated by the "|" character.

The following keys will be provided:

• [CenterFrequencyHertz] The tuned center frequency in Hz
• [BandwidthHertz] The bandwidth of the observation in Hz
• [OffsetHertz] The offset frequency (in case an LNB or up/down converter is used with the receiver)
• [NumberOfChannels] The number of frequency bins that will be provided for each scan line

The following keys may be provided:

• [IntegrationTimeSec] The amount of integration in seconds that will be used for each scan line
• [GainDb] The total amount of receiver gain used
• [NotesString] An ASCII string provided by the program to describe the observation (excluding the "|" character).

For example:
CenterFrequencyHertz 21000000|BandwidthHertz 5000000|OffsetHertz 0|NumberOfChannels 2048|

This would tell your program that the center frequency of the observation is 21 MHz. The bandwidth is 5 MHz, so the display will run from 21 + 2.5 to 21 - 2.5 MHz, or 18.5 MHz to 23.5 MHz. There is no offset so no frequency converter is used. Finally, NumberOfChannels denotes the number of channels that will be reported for each of the spectrum scans. There is no predefined limit on the number of channels, but the number is limited to a 4-byte unsigned integer. The connection block will be a fixed-size of 1024 bytes. Each of these parameters is separated by the pipe symbol "|". The parameter string will end with a CRLF. There may be trailing NUL to complete the 1024-byte connection block description.

Following this, a constant stream of binary data will be provided, the total size which is known after the connection string is parsed. It is not necessary to interpret the connection block (above) as the binary stream will self-describe itself. It will consist of the following binary data elements (equivalent to a binary-version of the rtl-power specification) in Network Byte Order:

• [timestamp] IEEE-754 8-byte double representing the seconds since January 1, 1970 (the Unix Epoch)
• [hz_low] IEEE-754 4-byte float representing the center frequency of the lowest frequency bin
• [hz_high] IEEE-754 4-byte float representing the center frequency of the highest frequency bin
• [hz_step] IEEE-754 4-byte float representing the difference between two adjacent frequency bins
• [samples] A 4-byte unsigned integer representing the number of samples used to integrate each frequency bin
• [channels] A 4-byte unsigned integer representing the number of frequency bins to follow
• [db-values] IEEE-754 4-byte float * channels (as given in the header above)

A useful set of links for timestamps is given here

There is a need to understand the behavior of the RASDR devices at the operating points that they are likely to be used. With a broadband noise source of known output power, one can sweep across the RASDR tuning range and gather statistical information of the performance of the receiver across all of its ranges. There should be no outside sources of energy except that which leaks in from the case, or is produced by internal components or the cables, etc. Knowing the bandwidth of the receiver as well as the gain/attenuation settings in the signal path allows one to predict what the response should be and compare that to what the response actually is.

For example, I was surpised by the following observations in which the only variation was sampling clock frequency when looking into an external 50ohm load SMA screwed on to the RX input port:

50ohm load, Fcenter=408.1MHz, 1.5MHz bandwidth, 10Msps

50ohm load, Fcenter=408.1MHz, 1.5MHz bandwidth, 8Msps

50ohm load, Fcenter=408.1MHz, 1.5MHz bandwidth, 4Msps

50ohm load, Fcenter=408.1MHz, 1.5MHz bandwidth, 2Msps

I think that one would make these observations and populate a database (or spreadsheet) with the metrics and then create some kind of a 'heatmap' of the performance changes as different parameters are varied. In a sense, 'visualizing' the behavior of the receiver under some handful of performance metrics. Here are some metrics I am thinking of:

1. DC balance: how far away from 'correct' the average value I and Q signal components are. For a calibrated noise source, they should have the same average value, and based on the bandwidth and gains that average value is a known quantity.
2. baseline flatness: So what I see with the RASDR, is that even looking into a 50ohm load, the receiver outputs some spurs and not all sample rates produce a flat spectral baseline. This is bad, and represents a pretty strong "quality" metric of the receiver system itself. Knowing where the "bodies are buried" is important to using the receiver effectively.
3. SFDR: this one is a bit tricky, as it needs a signal injected in it. But I can do that now. This tests the liklihood of intermodulation effects to interference signals. If we can quantify how the RASDR receiver is affected by signals inside the box as well as what might come through the LNA, we can develop a better filtering plan. I know that the LMS6002D has a pretty bad IP3 spec (-1dBm). Some references: IP3 Demystified, Cascaded 2-tone 3rd-order intercept point.
4. sensitivity: this would be the minimum signal level detectable by the device at a particular frequency, and naturally would be a function of the overal noise level in the receiver electronics itself.
5. NF/Noise Temperature: Probably should also characterize the device this way, as it is in common use. Some referenecs: On Noise Figures and Noise Temperatures, Three Methods of Noise Figure Measurement, Fundamentals of RF and Microwave Noise Figure Measurements

Each observation would be indexed by the following attributes:

• Device Serial Number
• Date of Observation
• Center Frequency
• LPF Bandwidth
• Sample Rate
• LNA Selected (LNA1, LNA2, LNA3 or 50ohm)
• LNA Gain mode (Max, Mid, or Bypass)
• VGA1 Gain
• VGA2 Gain
• Total received power (sqrt(I_I + Q_Q) in dBm)
• Calibrated noise source power (in dBm)

There is a desire to integrate RASDR software with Jim Sky's Radio Sky Spectrograph.

A document that describes a set of achievable experiments for astronomy observations with RASDR2. Several criteria are desirable:

1. experiments should have a range of difficulty, with a skill level clearly indicated
2. a step-by-step procedure with required materials and construction notes
3. expected output/screenshots to give confidence that folks are 'on the right track'

On Sun, Jul 3, 2016 at 8:39 PM, Tony Bigbee [email protected] wrote:

Setup FFT Output:
General Comma Delimited
Single
Zoom FFT Range Bins
Universal Time

Also, in the attached plot using the attached csv file, the frequencies are all listed as .1.  I believe that's not correct -- can you confirm?

c:\rasdr2\plotcsv>plotcsv.exe FFTOut-test-6.csv --statistics=stats.csv --smooth=
10 -a 32
range (MHz)=[0.095215,0.104980]
zero index=0
frequency bins=21
bandwidth/bin (Hz)=465.030000
start=2016-07-04 02:17:39.207000+00:00
end  =2016-07-04 02:17:46.719000+00:00
inter-frame period=0.124 sec (8 fr/s)
averaging=32
loading FFTOut-test-6.csv...
Saved spectrum-2016_Jul_04_02_17_42.png
Saved spectrum-2016_Jul_04_02_17_46.png

RASDR software should identify significant amplitude events (based on threshold or on command) by time, and record the brief event in a file in a "standard RASDR data record". We need to be able to export/import standard records for archiving and comparison between sites and at different times.

If you attempt to start RASDRproc over a remote desktop connection, it will eventually raise an unhandled exception. This seems to be a common problem with OpenGL programs as shown in this post.

I've created a branch to investigate it.

RASDR now uses Internet Time, but better accuracy and precision would result by using local clocks disciplined to GPS. We need to link in software to a disciplined clock. Radio astronomy sites using RASDR would be able to overlay pulse events and identify possible origins.

A low-drift clock would be an asset for pulsar searches that employ synchronous detection.

On Mon, Jul 11, 2016 at 2:45 AM, Tony Bigbee <> wrote:

Bogdan - I also discovered that the number of ffts to record is limited to 10000, which can amount to a very short session and bit me tonight.  It's set that way in the construction of the spinner input Line 179 of SetupFFTout.cpp

FFTsToRec = new wxSpinCtrl(this, ID_SPINCTRL1, _T("64"), wxDefaultPosition, wxSize(82,21), 0, 1, 10000, 64, _T("ID_SPINCTRL1"));

I suggest allowing the maximum to be the maximum int size.

There are an enormous amount of compiler warnings. This is a placeholder for commits to eliminate them.

There is a FAQ for LMS6002D that details many aspects of RFIC tuning. This ticket is to capture work needed to ensure that all of the recommendations are implemented.

On Sun, Jul 31, 2016 at 9:24 PM, Tony Bigbee [email protected] wrote:

I have been applying the DC tuning adjustments so often that I wish that instead of the 3 button clicks to open the frame, use current averages, and accept the values, there was a single button in the main interface to accomplish that.

RASDRviewer source requires copyright markings on all files prior to loading into github.
location of rasdrviewer will be: host\RASDRviewer\

Interfacing to SOAPY would permit using with a large variety of SDRs.

The RASDR code remains the only SDR code specifically designed for amateur radio astronomy use. It needs to be useable with more receivers, to achieve its true potential to the larger amateur radio astronomy community.

RASDR2 requires a TCP/IP socket server program to work with software such as Jim Sky's Radio Spectrograph.
The basic requirements for this interface are as follows:

1. startup and become a TCP/IP server, command line options set various parameters for system gain and bandwidth
2. accept one connection at a time, and send ASCII 'OK' upon a complete connection
3. receive an CRLF terminated ASCII block of data with key=value pairs to set various settings such as:
   • Fs=integer (sample frequency in KHz, min=750, max=40000)
   • Fc=scientific (center frequency in Hz, min=300e6, max=3.8e9)
4. upon receipt of the configuration parameters in #3 above, configure RASDR2 and continuously produce IQ data to the socket until disconnected. The IQ data will be interleaved 16-bit twos-complement values with no gaps in samples.

The pre-compiled raw2iq.exe program distributed with distribution-1.2.4 will not run on a system that does not have a Visual Studio 2013 compiler because it is missing a VCOMP120.DLL dependency.

An ExtIO_rasdr2.dll is to be developed to enable RASDR2 hardware to be used in a wide variety of existing Windows-based SDR software.
This software will allow beta-testers to evaluate RASDR2 hardware against similar devices such as RTL-SDR dongles, BladeRF, HackRF, SDR14 and other radios.
The specifications are distributed here