Re: [Discuss-gnuradio] Random number of output items
Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Random number of output items
Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe2FKAAoJEBQ6EdjyzlHtrvsH/3EhTVbESphbUfNeWmZe/rNU YYOVD7XVYVndHzstznIwvYlNVRLugjJw74pPJ0DS050b1ggc9mDK/mW4975BICau hQQktHxN3QReWk5qKwpAx6Y/+3bVpC+phyFzZO0+1TBwHNYexsVA+Zw0mkGrOuvA 3pInPREkJxqxcMrbZZhMTYVVDfOpB5MEjxHSKOMWyAQqop2fg1ahlEwpKjVqDmmV 9NhjSbIy29kpayTcEq525ha0QPMb5bRkRiP1sw4GqHDJZSHyUR4RWYYHiVfD3CvP /Bmx74UyS69gnP6NmMxun3OjWngpNHkJNC0lN/GGHVhz7YjwVXINuXNkbYuEVaM= =x2qL -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman
Re: [Discuss-gnuradio] Random number of output items
Thanks I'll take a closer look. On Tue, May 20, 2014 at 10:34 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi, PDU blocks are a *type* of blocks. Basically, you tag your sample stream so that the blocks downstream know how long your packet is. The tagged stream infrastructure is an innovation meant to simplify the design of blocks dealing with packetized data. Lool in the gr-digital/examples subfolder for how some implementations of that principle are used. Greetings, Marcus On Tue, May 20, 2014 at 4:23 PM, Francois Gervais francoisgerv...@gmail.com wrote: Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number of output, and return X if X == noutput_items: (either one of above) When you send out a sync byte, add that to the output count. When you are waiting for the preamble, you may want to send out a series of zeros, rather than just producing no output. Producing no output may cause the downstream blocks to become unresponsive. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG
Re: [Discuss-gnuradio] Random number of output items
Hi Marcus, I'm not sure about the steps required to translate the bit stream from the RF receiver into a tagged stream. I looked at the ofdm_rx example and from what I understand I'll need a first block that takes the output of the demod/Clock Recovery/bit slicer and find the packets inside the stream and tag it so the other blocks can work with the tagged stream. This first block is a normal one that inherit from the generic Block class it that it? Does this first block need to output anything while waiting for the preamble of a packet to prevent the downstream block from freezing? Once the stream is packetized and tagged it seems pretty straight forward. Thanks On Tue, May 20, 2014 at 10:37 AM, Francois Gervais francoisgerv...@gmail.com wrote: Thanks I'll take a closer look. On Tue, May 20, 2014 at 10:34 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi, PDU blocks are a *type* of blocks. Basically, you tag your sample stream so that the blocks downstream know how long your packet is. The tagged stream infrastructure is an innovation meant to simplify the design of blocks dealing with packetized data. Lool in the gr-digital/examples subfolder for how some implementations of that principle are used. Greetings, Marcus On Tue, May 20, 2014 at 4:23 PM, Francois Gervais francoisgerv...@gmail.com wrote: Sorry about that I'll try to clarify thing. I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it and send it through the MM clock recovery and bit slicer. Then the binary signal enters the block I'm talking about here. This block find a valid packet by matching the preamble and the sync pattern and translates the packet into another format that is understood by a software stack designed for these type of packets. Normally this stack would take it's input from a serial port but in my case I output the packets in the correct serial protocol through a file sink that is binded to a FIFO. I'll take a look at the PDU block but this translation needs to be done between two very specific protocol. I don't think a generic block can achieve that. Right now the development is mostly finished. All I need to make sure is that my block interface correctly with the scheduler since I don't have a fixed input to output number relationship. It's mostly 8:1 but that not always exactly the case. Hope it makes sense. On Tue, May 20, 2014 at 10:06 AM, Marcus Müller mar...@hostalia.dewrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Francois, as Activecat, I'm kind of having a hard time understanidng your requirements. If you're emulating a hardware signal source, go for the source approach. If you're basically taking input from anywhere and packing it into packets of varying length, that's exactly what the PDU block infrastructure is for: http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html Greetings, Marcus On 20.05.2014 15:59, Francois Gervais wrote: Thanks Activecat you actually answered quite well to my question. I thought it might be better to send 0s, i'm glad you confirmed that. And thanks for the output algorithm. Could you tell me more about forecast? Most of the time I need 8 input samples to produce one byte output so I set the forecast like so: ninput_items_required[0] = noutput_items*8; It seems pretty straight forward. Is this correct? On Mon, May 19, 2014 at 9:32 PM, Activecat active...@gmail.com wrote: On Tue, May 20, 2014 at 2:17 AM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? If your block emulates a USB adapter, defines it as a source block, then you don't need to touch forecast(). If your block takes input from another block, then it is not source block. I don't really understand your requirements. The number of outputs (referred as noutput_items) is determined by the scheduler, not yourself. Says, when you have X bytes to send out, if X noutput_items: Send out noutput_items number of output, and return noutput_items if X noutput_items: Send out X number
[Discuss-gnuradio] Random number of output items
Hi, I'm making a block which takes bit from a bit slicer and output packets as input comes in. My block will output bytes so it can emulate a usb adapter that receives the RF signal and output a packet stream through an FTDI. That way I can use the stack that comes with the adapter without owning one. I'll use a FIFO file so other than not issuing the serail configuration the stack should be used pretty much as is. However, I'm not sure what I should do about the the number of outputs. Let say I'm waiting for the preamble, I won't output anything. When I get the preamble and the sync I'll send a sync byte of my own. From here every 8 inputs I'll output a byte. So basically my block will output 0 or 1 output. Can someone help me a little with the use of forecast and noutput_items in my case? Also do I need to use the consume_each function? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Best way to output decoded data to user
Well I'm thinking if I'm about to print text to user it's better if it's part of the GUI than having some of the information on the GUI and some on the underneath console. That way it looks more like a self contained app to me. On Tue, Apr 15, 2014 at 12:13 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Apr 15, 2014 at 12:03 PM, Martin Braun martin.br...@ettus.comwrote: On 04/15/2014 03:55 PM, Francois Gervais wrote: Ah so message queue and message passing interface are two different things in gnuradio? Might be why I was confused. So what I want to look at is this page right? http://gnuradio.org/doc/doxygen/page_msg_passing.html Right. Got it I'll for the WX widgets, I'll stop using them. Is there an official QT terminal block? Not yet :) If you want to get your hands dirty, that would be nice... Martin Someone actually uses the terminal block? That one in WX has always felt completely broken to me and I had no interest in duplicating it in QT. But hey, if it's being used, it's something we would like to have. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Best way to output decoded data to user
Hi, I'm trying to figure out the best way to print the decoded data information of packets (received through gnuradio) to the user. File outputs are not really user friendly so I'm thinking of using a message queue out of my decoding block connected to the WX GUI Terminal Sink. Is this a good approach? I'm thinking it might not since I can't find any design using the terminal sink on the net. If this is the right path could someone point me to an easy example of using the message queue. I'd like to do a quick proof of concept and output something like hello world on the terminal sink. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ASK demodulation help
Any idea on this? Should I post the images somewhere else? On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais francoisgerv...@gmail.com wrote: I tried using the MM clock recovery block as suggested and I have a little fidelity problem. I added two screenshot links below which show the problem. I would say 70% of the time the recovered data is fine but for some reason it's sometimes badly distorted. By looking at it, the input signal looks always about the same. Is there something obviously wrong in what I'm doing? ASK demodulation GRC https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing Signal in and out of Clock recovery block https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury john.malsb...@ettus.comwrote: I don't know if I would call it overkill. It is just one of several methods you can use to achieve synchronization. Other options for synchronization include correlate and sync (probably needs modification), or possible the polyphase resync. Others on the list would have more expertise on these blocks. In my experience 10 samples per symbol seems to work well with MM. I've heard very high samp/sym (ie. 20) can cause problems, but I haven't seen this myself. The amplitude going into MM should be as close as possible to +/- 1.0, which is why you want the scaling functions before this block. The AGC block assures you're working with something constant amplitude for demodulation. -John On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais francoisgerv...@gmail.com wrote: Thanks guys for the information, I looked a little about the MM recovery block but it seemed to me like and advance algorithm, overkill for what I'm trying to achieve. I'm I mistaken? If I'm using the MM clock recovery block what is the quality of input signal I should aim to avoid translation errors? Should my signal be filtered with a really narrow band and should I allow more harmonics in to the signal is more square? Can the input signal have too much sample per bit? Right now I'm at 16. Is more better? Is it better to have more amplitude? Thanks On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury john.malsb...@ettus.comwrote: Depending on various factors the implementation may vary, but you could probably start with a chain that looks something like this: I/q source - filter - AGC - AM demod (complex to mag) - scaling for am depth - mm clock recovery - slicer - do something with the data Other, more advanced implementations might use correlation for synchronization. -John On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal from a device I have, as a first project. I'm using RTL-SDR as the input device. I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass filter it to 300khz, I send it through the AM demodulation block and then through the DC blocker. From there I have my signal and it looks fine i.e I could retrieve the information manually by looking at it. Now I think the goal is to somehow synchronize with the bits and re-sample to get 1 sample per bit. This could then be sent to a file. Is that it? At first glance I'm thinking I should have a PLL which ouputs a clock at about 250khz (twice the bit rate) and synchronize the rising edge with every bit transitioning from 0 to 1 so unless I receive only ones ou zeros I should be quite in sync. Then I could toggle a sample every falling edge of the clock which should be at about the middle of the bit. Is this a viable solution? Can it be done with gnuradio? Other alternatives? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ASK demodulation help
That could explain it. However most of the time it locks just fine even for the preamble with the same block parameters. I'm not sure what causes this variability and if I have control over it of not. Might be related to when the MM clock recovery starts sampling the signal. Sometimes it's lucky and start sampling the bit close to a bit frontier and sometimes not so it needs to adjust on the next bit. Could that make sense? On Fri, Apr 11, 2014 at 1:19 PM, Nick Foster bistrom...@gmail.com wrote: To me it looks like it's taking some time to acquire, which is normal for a closed-loop timing recovery algorithm. This is one reason packets have preambles. If you need it to lock faster and don't mind some self-noise, and if the SNR is high enough, you can turn up the gain of the MM block (change 0.175 in both gain mu and gain omega to a larger number) to allow it to lock faster. --n On Fri, Apr 11, 2014 at 9:59 AM, Francois Gervais francoisgerv...@gmail.com wrote: Any idea on this? Should I post the images somewhere else? On Thu, Apr 10, 2014 at 11:11 PM, Francois Gervais francoisgerv...@gmail.com wrote: I tried using the MM clock recovery block as suggested and I have a little fidelity problem. I added two screenshot links below which show the problem. I would say 70% of the time the recovered data is fine but for some reason it's sometimes badly distorted. By looking at it, the input signal looks always about the same. Is there something obviously wrong in what I'm doing? ASK demodulation GRC https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing Signal in and out of Clock recovery block https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury john.malsb...@ettus.comwrote: I don't know if I would call it overkill. It is just one of several methods you can use to achieve synchronization. Other options for synchronization include correlate and sync (probably needs modification), or possible the polyphase resync. Others on the list would have more expertise on these blocks. In my experience 10 samples per symbol seems to work well with MM. I've heard very high samp/sym (ie. 20) can cause problems, but I haven't seen this myself. The amplitude going into MM should be as close as possible to +/- 1.0, which is why you want the scaling functions before this block. The AGC block assures you're working with something constant amplitude for demodulation. -John On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais francoisgerv...@gmail.com wrote: Thanks guys for the information, I looked a little about the MM recovery block but it seemed to me like and advance algorithm, overkill for what I'm trying to achieve. I'm I mistaken? If I'm using the MM clock recovery block what is the quality of input signal I should aim to avoid translation errors? Should my signal be filtered with a really narrow band and should I allow more harmonics in to the signal is more square? Can the input signal have too much sample per bit? Right now I'm at 16. Is more better? Is it better to have more amplitude? Thanks On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury john.malsb...@ettus.com wrote: Depending on various factors the implementation may vary, but you could probably start with a chain that looks something like this: I/q source - filter - AGC - AM demod (complex to mag) - scaling for am depth - mm clock recovery - slicer - do something with the data Other, more advanced implementations might use correlation for synchronization. -John On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal from a device I have, as a first project. I'm using RTL-SDR as the input device. I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass filter it to 300khz, I send it through the AM demodulation block and then through the DC blocker. From there I have my signal and it looks fine i.e I could retrieve the information manually by looking at it. Now I think the goal is to somehow synchronize with the bits and re-sample to get 1 sample per bit. This could then be sent to a file. Is that it? At first glance I'm thinking I should have a PLL which ouputs a clock at about 250khz (twice the bit rate) and synchronize the rising edge with every bit transitioning from 0 to 1 so unless I receive only ones ou zeros I should be quite in sync. Then I could toggle a sample every falling edge of the clock which should be at about the middle of the bit. Is this a viable solution? Can it be done with gnuradio? Other alternatives? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ASK demodulation help
I tried using the MM clock recovery block as suggested and I have a little fidelity problem. I added two screenshot links below which show the problem. I would say 70% of the time the recovered data is fine but for some reason it's sometimes badly distorted. By looking at it, the input signal looks always about the same. Is there something obviously wrong in what I'm doing? ASK demodulation GRC https://drive.google.com/file/d/0B_ApAHfP4naZaE5WRUJHWUtHUEU/edit?usp=sharing Signal in and out of Clock recovery block https://drive.google.com/file/d/0B_ApAHfP4naZY3Ryblp3cFlrdGs/edit?usp=sharing On Wed, Apr 9, 2014 at 5:27 PM, John Malsbury john.malsb...@ettus.comwrote: I don't know if I would call it overkill. It is just one of several methods you can use to achieve synchronization. Other options for synchronization include correlate and sync (probably needs modification), or possible the polyphase resync. Others on the list would have more expertise on these blocks. In my experience 10 samples per symbol seems to work well with MM. I've heard very high samp/sym (ie. 20) can cause problems, but I haven't seen this myself. The amplitude going into MM should be as close as possible to +/- 1.0, which is why you want the scaling functions before this block. The AGC block assures you're working with something constant amplitude for demodulation. -John On Wed, Apr 9, 2014 at 2:04 PM, Francois Gervais francoisgerv...@gmail.com wrote: Thanks guys for the information, I looked a little about the MM recovery block but it seemed to me like and advance algorithm, overkill for what I'm trying to achieve. I'm I mistaken? If I'm using the MM clock recovery block what is the quality of input signal I should aim to avoid translation errors? Should my signal be filtered with a really narrow band and should I allow more harmonics in to the signal is more square? Can the input signal have too much sample per bit? Right now I'm at 16. Is more better? Is it better to have more amplitude? Thanks On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury john.malsb...@ettus.comwrote: Depending on various factors the implementation may vary, but you could probably start with a chain that looks something like this: I/q source - filter - AGC - AM demod (complex to mag) - scaling for am depth - mm clock recovery - slicer - do something with the data Other, more advanced implementations might use correlation for synchronization. -John On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal from a device I have, as a first project. I'm using RTL-SDR as the input device. I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass filter it to 300khz, I send it through the AM demodulation block and then through the DC blocker. From there I have my signal and it looks fine i.e I could retrieve the information manually by looking at it. Now I think the goal is to somehow synchronize with the bits and re-sample to get 1 sample per bit. This could then be sent to a file. Is that it? At first glance I'm thinking I should have a PLL which ouputs a clock at about 250khz (twice the bit rate) and synchronize the rising edge with every bit transitioning from 0 to 1 so unless I receive only ones ou zeros I should be quite in sync. Then I could toggle a sample every falling edge of the clock which should be at about the middle of the bit. Is this a viable solution? Can it be done with gnuradio? Other alternatives? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ASK demodulation help
Hi, I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal from a device I have, as a first project. I'm using RTL-SDR as the input device. I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass filter it to 300khz, I send it through the AM demodulation block and then through the DC blocker. From there I have my signal and it looks fine i.e I could retrieve the information manually by looking at it. Now I think the goal is to somehow synchronize with the bits and re-sample to get 1 sample per bit. This could then be sent to a file. Is that it? At first glance I'm thinking I should have a PLL which ouputs a clock at about 250khz (twice the bit rate) and synchronize the rising edge with every bit transitioning from 0 to 1 so unless I receive only ones ou zeros I should be quite in sync. Then I could toggle a sample every falling edge of the clock which should be at about the middle of the bit. Is this a viable solution? Can it be done with gnuradio? Other alternatives? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ASK demodulation help
Thanks guys for the information, I looked a little about the MM recovery block but it seemed to me like and advance algorithm, overkill for what I'm trying to achieve. I'm I mistaken? If I'm using the MM clock recovery block what is the quality of input signal I should aim to avoid translation errors? Should my signal be filtered with a really narrow band and should I allow more harmonics in to the signal is more square? Can the input signal have too much sample per bit? Right now I'm at 16. Is more better? Is it better to have more amplitude? Thanks On Wed, Apr 9, 2014 at 4:31 PM, John Malsbury john.malsb...@ettus.comwrote: Depending on various factors the implementation may vary, but you could probably start with a chain that looks something like this: I/q source - filter - AGC - AM demod (complex to mag) - scaling for am depth - mm clock recovery - slicer - do something with the data Other, more advanced implementations might use correlation for synchronization. -John On Wed, Apr 9, 2014 at 1:27 PM, Francois Gervais francoisgerv...@gmail.com wrote: Hi, I'm new to gnu radio and I'm trying to demodulate a 125kpbs ASK signal from a device I have, as a first project. I'm using RTL-SDR as the input device. I'm slowly getting there. I receive the signal, at 2Msample/s, I low-pass filter it to 300khz, I send it through the AM demodulation block and then through the DC blocker. From there I have my signal and it looks fine i.e I could retrieve the information manually by looking at it. Now I think the goal is to somehow synchronize with the bits and re-sample to get 1 sample per bit. This could then be sent to a file. Is that it? At first glance I'm thinking I should have a PLL which ouputs a clock at about 250khz (twice the bit rate) and synchronize the rising edge with every bit transitioning from 0 to 1 so unless I receive only ones ou zeros I should be quite in sync. Then I could toggle a sample every falling edge of the clock which should be at about the middle of the bit. Is this a viable solution? Can it be done with gnuradio? Other alternatives? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
