ZMQ source from GNURadio

[muaddib1984]

Is it possible to send the audio stream into JAERO from a ZMQ pub sink in GNURadio? Or is there another way to send data from GNURadio into JAERO?

I am currently sending some data from a pub sink and JAERO's FFT isn't showing anything at all.

[jontio]

Have a look at the format of the zmq messages in https://github.com/jontio/JAERO/blob/master/JAERO/zmq_audioreceiver.cpp

        //rate message is next
#ifdef ZMQ_HAS_SAMPLERATE_MESSAGE
        received = zmq_recv(subscriber, rate, 4, ZMQ_DONTWAIT);
        if(!running)break;
        memcpy(&sampleRate, rate, 4);
#endif

        //then audio data
        received = zmq_recv(subscriber, buf, recsize, ZMQ_DONTWAIT);
        if(!running)break;
        if(received>=0)
        {
            QByteArray qdata(buf, received);
            emit recAudio(qdata,sampleRate);
        }

You are probably missing the sample rate as the first message.

[muaddib1984]

thank you for your response. i've still been trying to get zmq messages into JAERO from GNURadio with no luck. I have a flowgraph that connects a wav file source to a zmq socket and i'm using the sample audio files from JAERO. I have another flowgraph that plays the files back to the audio sink. The audio sink works fine, so I know JAERO is installed correctly, but when I use the ZMQ sink with the correct topic "JAERO", I can't see anything at all in the window. I can tap the ZMQ stream with a python zmq sub script and see the topic and the data so I know it's a valid stream. I just tried to comment out the https://github.com/jontio/JAERO/blob/3d92aea9362e0565bc6bc5300391a8bbbecf93ed/JAERO/zmq_audioreceiver.cpp#L10 line to not require a sample rate message. I did this as a workaound in hopes that JAERO will at least be able to read the ZMQ stream with only a topic and the audio stream. So far that isn't working either. Is there a debug/error output that can be enabled to show if the topic is correct, but the message type is incorrect/missing? What is the datatype that JAERO expects coming into the zmq audio receiver? I think making JAERO 'compatible' with GNURadio as the SDR receiver and USB demod would be a really cool thing, so want to keep trying!

[jontio]

No you'll have to put in your own debugging as needed, qdebug is what I usually use which sends it to the stdio; you should only need to modify JAERO/JAERO/zmq_audioreceiver.cpp

The audio data when it leaves zmq_audioreceiver.cpp should be signed 16-bit integer mono packed in a qbytearray.

Yup commenting out #define ZMQ_HAS_SAMPLERATE_MESSAGE will make things easier as you don't need to supply the sample rate in that case.

[muaddib1984]

awesome, thanks so much for the quick reply!

[muaddib1984]

Do you happen to have any raw IQ files that I could use to test with a GNURadio USB demodulator?

Regarding the zmq_audioreceiver.cpp I believe it expects input data to be 16bit shorts. Is that correct?

FYI, I got a hacky prototype working so I thought I'd share (assuming you're interested).

The GNURadio PUB Sink in GNURadio 3.9+ has the 'topic' field and sends it as a separate message, just like SDRReceiver does to JAERO. The rate field is the tricky part. For now, i've written a ZMQ PUB Sink Python block to replace the ZMQ PUB Sink C++ block in GNURadio. Mine sends the messages in the desired format. If I was better with C++ I could probably just add the extra field, but that's a little outside of my skill set.

Currently I have a flowgraph with a wav file source playing back a couple of the wav files from JAERO's 'samples' directories. I've attached a screenshot.

I'm working on a better mechanism for this, so hopefully this will be forthcoming.

[jontio]

Do you happen to have any raw IQ files that I could use to test with a GNURadio USB demodulator?

I had a look on my cloud storage and I see a few of the original signals I used when starting JAERO. I think they only contain 600bps but I haven't looked too closely; here they are...

https://drive.google.com/file/d/0B1561PAMx6wiM0tIZ0NmV3hRTGM/view?usp=sharing&resourcekey=0-_qo25AUmF2sGI0yekr5otw https://drive.google.com/file/d/0B1561PAMx6wiTkdyb0E0RlZHQ28/view?usp=sharing&resourcekey=0-he3DTDA22SA51ouC-V_k7g https://drive.google.com/file/d/0B1561PAMx6wiTmdxU2NndTl6ZEk/view?usp=sharing&resourcekey=0-Vdcx-yIldKUAKTIemG4OTA

Regarding the zmq_audioreceiver.cpp I believe it expects input data to be 16bit shorts. Is that correct?

Yup, as I recall.

The GNURadio PUB Sink in GNURadio 3.9+ has the 'topic' field and sends it as a separate message, just like SDRReceiver does to JAERO. The rate field is the tricky part. For now, i've written a ZMQ PUB Sink Python block to replace the ZMQ PUB Sink C++ block in GNURadio. Mine sends the messages in the desired format. If I was better with C++ I could probably just add the extra field, but that's a little outside of my skill set.

Currently I have a flowgraph with a wav file source playing back a couple of the wav files from JAERO's 'samples' directories. I've attached a screenshot.

I'm working on a better mechanism for this, so hopefully this will be forthcoming.

Interesting. I've had a quick look at GNU radio in the past but didn't get far; I'm a lot better with getting things working with C/C++. As I recall before I started looking at the signals, Oscar had already thought about using GNU radio to demodulate the 600buad Inmarsat signals.

[muaddib1984]

Thank you so much for the wav files. I've been working with them for a few days. I'm still unclear fundamentally how you are able to recover the QPSK constellation from USB audio. I'm reading a lot of your posts and trying to work through the theory of operation. Is the AM demod just an intermediate step to get an audio representation of the RF spectrum or is AM modulation part of the protocol itself? ~~Currently I have an SSB receiver in GNURadio piping audio to JAERO which seems to be at least receiving the audio, but no messages so far. A couple of times I can see a (1,1) (-1,-1) BPSK constellation pop up, but that could really just mean i'm giving the demods really 'convincing' audio :D At the audio input stage in JAERO what is it expecting to see from the demodulated audio?~~ Ok, I got it working for 600 bps channels. I built the flowgraph from the GNURadio AM SSB example, so nothing fancy or custom needed. It's running over the built in ALSA audio driver just fine.

[muaddib1984]

@jontio I now have the demod working consistently with my own captures. I posted some cool screenshots here. Wondering if you can think of any reason I would get 600/1200 no problem (and very few Bad CRC messages) but can't seem to get 8400 or 10500 working at all. I've read most of your research and believe that I am seeing at least a few channels. JAERO volume is green and the 'signal' light goes green for a bit then goes off. The constellation is also all over the place. Any thoughts or issues you've had that might help with this?

[jontio]

10500 is much weaker than 600. 8400 is weaker still. Anything that's 10dB above the noise floor should be easily decodable. A 60 cm dish should be enough for 10500.

I don't really know much about GNURadio but there could still be something amiss with your design. I would check using something like SDR# and compare that to your GNURadio implementation; that might help you figure out what the problem is.

I don't know if GNURadio can do it but the first thing I would've done would be take your incoming IQ stream that you seem to be getting from two separate sources and combine them into a complex number then perform the mixing on that. Then the filtering on that. If GNURadio allows doing everything on complex numbers that should simplify things.

[muaddib1984]

Thanks. The flowgraph has more to it, I wanted to show the USB portion to @jeroenbeijer since it's a near perfect replica of his USB demod. If you have any interest in GNURadio I'd be happy to help you there. The community would benefit from having you as a user or contributor! What I've done upstream from the USB is exactly what you said,complex in, frequency shift (to center the spectrum around a specific carrier) low-pass and decimation to 48khz, then split the complex stream into real and imaginary and perform the USB demod (the portion shown on my SDRReceiver post). After I posted on here, I went back and tested another one of your IQ WAV files with my new USB and It worked perfectly on 10500! I didn't realize those files had them until I took a second look. That being said, I did notice a spectral inversion between my IQ capture and yours. That can be handled with either a complex conjugate block or just flip the I and Q.

After i run a few more tests and get the flowgraphs cleaned up, I'm planning on releasing my USB demodulator and the GNURadio to JAERO ZMQ adapter block as a GNURadio Out-of-Tree module. I'll of course be pointing the whole project at JAERO as my blocks don't handle any digital demod/decoding.

Are you ok if I call it gr-JAERO?

[jontio]

Yup, sure. I don't mind if you call it gr-JAERO.

Yes, I don't often pay much attention to which way the IQ goes around and instead just flip them if it's needed.

[muaddib1984]

Here's my GNURadio to JAERO interface project. I gave you a shoutout in the CREDITS section. Thank you so much for your help!

[jontio]

You're welcome. Thanks.

[muaddib1984]

I have now been able to receive 600,1200,8400,10500 and C-Band 10500 burst data with JAERO using GNURadio as the demodulator! Closing issue, thanks so much @jontio !