search

bastibl / gr-ieee802-15-4

IEEE 802.15.4 ZigBee Transceiver
https://www.wime-project.net
GNU General Public License v3.0
270 stars 87 forks source link

Vector Insert block not working on loopback #38

Closed rmendes1 closed 5 years ago

rmendes1 commented 5 years ago

Hello, could you help me with this?

I was trying to run the loopback file but when i did it, this error occurred

whatsapp image 2018-12-03 at 14 22 05

It says something like an error in the Vector Insert block. I tried to put it in bypass mode and it worked normally with this flowgraphs

image

I want to know if this error is because there's something that I forgot to install or parameters that need to be changed.

bastibl commented 5 years ago

I couldn't reproduce the problem. If you bypass the block, the frames are sent back-to-back. If this is OK for you, no problem. If you need some zeros in between, you can also try the burst shaper block. It does something similar.

rmendes1 commented 5 years ago

When I opened the loopback file for the first time to run, it gave me that error of the fist image in the commentary above. I didn't know how to interpret what kind of error was, just understood that was something to do with the Vector Insert block. So I simply bypass the block to see what could happen, that is the flowgraphs generated in the second image.

image

that's the parameters of the block, so what I was trying to know is if I need to change something to make it work

bastibl commented 5 years ago

Try changing the offset to 0, but, again, if the block doesn't work for you, replace it with, for example, the burst shaper block, which does something similar.

rmendes1 commented 5 years ago

Changing the offset to 0, I get a similar result. Is this working correctly?

image

I tried with burst shaper block, but it gave me no flowgraphs

bastibl commented 5 years ago

No idea what you mean with "it gave no flow graphs". And yes, I think it is working, but it's hard to judge if you just post the frequency plot... Also, I have no idea what you are trying to do, so how can I tell you if it is working.

rmendes1 commented 5 years ago

Ok, sorry. I'm new on this, and still trying to understand some concepts. The IEEE 802.11 archives was a little bit easier to understand the loopback example, because I just executed and it showed me the constellation graph. But I'm having difficulty with the 802.15.4.

So, that's the loopback file as I downloaded transceiver_css_loopback grc

First of all, I just wanted to run and see what it would generate. When I generated and executed, it was returning an error with the Vector Insert block. So I did what you told me to do that was change the offset to 0. What was generated is the following

image (the part of the image that is missing just shows the label of the 2nd graph)

What I wanted to know is if that's what supposed to be generated by default.

bastibl commented 5 years ago

I don't understand your way to approach this. The fact that you wouldn't know that it's working when it's working suggests that, in any way, you'll have to familiarize yourself a bit more with what is going on.

All I see is that something is plotted, which mainly means that something is happening. From the plot it's hard to tell if any data is decoded. If something is decoded, it's usually indicated by 'MAC: correct crc. Propagate packet to APP layer.' messages on the terminal output.

rmendes1 commented 5 years ago

Yes, that's the message the output terminal is showing. Also, another thing that I didn't understand is why the center frequency is 0 by default in the blocks

I'm using a LimeSDR-Mini instead of a USRP, is it possible to transmit/receive normally just changing the respective blocks?

bastibl commented 5 years ago

The loopback flow graph is a base band simulation. There is no hardware involved. The "center frequency" of the graphical outputs just relabels the x-axis.

I'm not sure if the CSS PHY can be sent over the air. But if you want to do it, you should adapt the _USRP verion, which is the one that actually uses hardware. Just replace the USRP source/sink with sources and sinks for your SDR.

Btw, if you are not explicitly told to use the CSS PHY, you are probably supposed to use QPSK version...

rmendes1 commented 5 years ago

Ok, I'll try it! Thank you so much for your help and patience! I just have one last question, just in case you know it. I'm trying to know if it is possible to change the channel BW of a given baseband technology (ZigBee or Wi-Fi in this case) via GNURadio. For example, in ZigBee we have a 2 MHz channel BW, and I want to channelize it with 1.25 MHz via SDR, using GNU. Is this possible?

bastibl commented 5 years ago

For an SDR that's merely a change of sample rate (at sender and receiver). The WLAN module supports this out of the box, since different bandwidth modes are defined in the standard. For WLAN, a 10MHz signal uses a sample rate of 10MHz. For ZigBee, the 2MHz signal uses a sample rate of 4MHz. So to switch to 1.25MHz, you have to change the sample rate (of the SDR source/sink blocks) to 2.5MHz.

rmendes1 commented 5 years ago

Again, thanks for your help! Another question that I was thinking is if in the WLAN case it's possible to put an SSID into it?

bastibl commented 5 years ago

This is a PHY implementation. You can send any data with it, including a beacon frame with an SSID. However, the transceiver does not support you with creating the payload, as this would usually be done by a higher layer. You can, for example, use the transceiver with Scapy (which will assist you in creating the beacon frame).

See this blog post: https://www.bastibl.net/gnuradio-wlan-scapy/