Basic communication question, multiple wixels (same channel)

Hello!

I’m trying to create a wireless mesh network using wixel boards (including a server/master and multiple repeaters and clients/slaves on the same channel without allowing any CRC errors).
I’ve thought about a way of realizing the communication using a protocol.
A packet would consist in a long string (~100-200 char long: e.g. some_stuff|wixel_sn1:wixel_sn2:…:wixel_snX|other_stuff).
I studied the sample applications, and if i understood correctly from the wireless_adc_tx app, i will have to use the radioQueueTxSendPacket() function which depends on RADIO_QUEUE_PAYLOAD_SIZE (=19).
Can i change this value up to 255 without having any issue, or the given string needs to be dismembered to 18 character sized packets?
I’d like to ask for the easiest way of sending this kind of information between two wixels (maybe a small code snippet transferring a longer character array).

Any advice would be appreciated!
Thanks in advance.

Hello. Yes, you can just change RADIO_QUEUE_PAYLOAD_SIZE in radio_queue.h to allow bigger packets. There are some limitations and tradeoffs to be aware of:

  • The PKTLEN register is an 8-bit register so there is no way to have packets longer than 255 bytes.
  • radio_queue.c reserves RAM memory for 19 packets (3 RX, 16 TX) so increasing the packet size without changing the number of packets could take up all of your RAM.
  • Longer packets will probably be lost more often due to noise, and on-air collisions become more likely.

If you were thinking of encoding the Wixel serial numbers as a ASCII strings, I recommend against it because it will make the packet unnecessarily long; each serial number only needs 4 bytes.

–David

I have a question on this topic.
I was wonder if you can split the load receiving and sending, something like Hughes net uses. They use 2 satellites to communicate to the internet. This will be the same principle for the wixel network.

My question is, would it work?

I believe this how it would work. there would be 2modes. The first mode have one wixel receive and the other one sends. The second mode would have them both receive and sending, by waiting until both are full and sending information with a delay like 1microsecond between the two sending the information. So the 2 wixels receiving can properly share the information.

Since the Wixel is programmable, I think you could make something like this work. Even without programming, you could get two pairs of Wixels running the Wireless Serial App and configure each pair to operate on different channels (frequencies). Then you could use one pair for sending data and another pair for receiving data from a remote robot. If you are doing full-duplex communication this could help you get a higher throughput.

I don’t really understand what your modes are and how they would work. A delay of 1 microsecond is negligible because transmitting a packet takes several hundred microseconds.

–David

DavidEGrayson[quote]
Since the Wixel is programmable, I think you could make something like this work. Even without programming, you could get two pairs of Wixels running the Wireless Serial App and configure each pair to operate on different channels (frequencies). Then you could use one pair for sending data and another pair for receiving data from a remote robot. If you are doing full-duplex communication this could help you get a higher throughput.[/quote]
This answer my question thank you

Hello

I’d like to figure out how can my wixels restart each other every time when i connect them to a computer. I have a full-duplex wireless connection between them, and i use two different computers to monitor the packets. There’s no problem while using an external power supply, but after i connect them to the USB port they send each other a restart signal (it happens only ONCE, but everytime at reconnect).

I suppose this happens because of a memory leak, or the SDCC overoptimizes something?!
e.g.: i’ve appended a method (without calling it) to my working app, and the wixel halted instantly…or similar issues with the printf() function (even if i call every time the usbComTxAvailable() first)

Has anyone experienced issues with the compiler?

Thanks for the help

Hello, Stevie.

What do you mean by “wixels restart each other”? The radio_link library sends reset packets at various points to keep things in sync, but this is just an implementation detail of that protocol and I don’t know why you would be concerned with it. What exactly is the problem, and what app are you running on the Wixel to reproduce the problem?

–David

Hello David.

I wrote my own code using the wireless_adc_tx/rx apps as guidance. At first I thought that I messed something up, but eventually I figured out, that the resets had a syncing purpose. It was a bit annoying while I was monitoring/debugging my network’s central node with a serial port monitor. Every time i connected/reconnected a client, it restarted the central node causing the port monitor to disconnect, but now most of my problems seem to be fixed :slight_smile:

Thank you for your time!

Those apps don’t use radio_link if I recall correctly, so there should be no reset packets. Also, the reset packets should not result in the USB connection getting reset as you described. The USB and the radio are handled by different libraries.

–David

I was using the radio_link library for handshake management between two devices (not anymore).
Because the problem apparently worked out itself, i think it was a memory leak, or something with the compiler.