current status and plan

[AnasIbrahim]

I'll regularly update the current status and what should be done next here

[AnasIbrahim]

current status: multiple floods can be achieved

here N TX = 3 and 2 nodes other than the initiator are sending.

next:

• small code clean up

• packet time: on the spectrum analyzer the packet takes around 4 ms time, it can take less. What RF parameter needs to be changed? (help) If we achieved this then we can reduce glossy flood time to less than 5 ms

• glossy statistics functions: implement glossy statistics functions (from glossy.h) and think about the results reasoning and the extra HW and SW needed.

• power and sleep: as the TX time till now is handled by the ti-firmware, I'm not sure if the main core and radio core achieve the best power saving. everything is scheduled as callbacks, not to keep the main processor powered up, but still maybe a better power optimization can be done manually

[AnasIbrahim]

@akrv I tried to use another RF setting to reduce the total time of Glossy flood. Before I was using (50 kbps 2-GFSK 25 kHz deviation) and for this setting one packet takes around 5ms. So I did a test with (500 kbps 2-GFSK 175 Khz deviation) and now one packet takes 375us and the whole time for a one hop glossy flood with N_TX=3 sending 8 bytes takes 4ms.

[akrv]

can you collect the data packet error rate for three scenarios? 100 glossy floods with 3 rounds. for 50Kbps (low data rate), 250 Kbps (IEEE 15.4 data rate) and 500 Kbps (high data rate). how much time it takes, so we can average it and how many bytes we are sending?

[collect this data in CSV format.] [images like these are also super helpful]

[AnasIbrahim]

@akrv should I collect this data with 8 bytes packet or ?

[akrv]

Bytes: 8,64,128,256 128 is necessary. 256 is the standard spec. 64 and 8 to show how it works at low data rates.

[AnasIbrahim]

I was fixing the Radio queue to fit for 256 byte packets (radio max is 255 so we end up with 254 byte to send) and wrote some of the statistics function.

For our configuration now there is no packet error (no crc error) so the csv file end up as (0,0,0,0,0,0, ...). I was thinking about adding some other readings, so the file makes more sense !

[AnasIbrahim]

these are the statistics function from glossy.h:

• total number of received packets with CRC ok
• the number of received packets with CRC failed during the last flood
• the signal-to-noise ratio (average RSSI value of all received packets of the last flood minus RSSI of the noise floor before the flood)
• the average RSSI value of the last flood
• brief get the relay count of the first received packet
• brief get the relay count of the last 3 packets (last flood)
• brief get the packet error rate/ratio in percentages * 100
• flood success rate (percentage of successful floods), not counting floods where no communication was detected (absence of preamble + sync byte) and the initiated floods
• get the total number of received packets including corrupt packets
• get the total number of received packets (with CRC ok only)
• get the total number of errors which occurred (RF RX/TX error)
• get the duration of the last flood, in HF clock ticks
• get the time to the first RX (since glossy_start), in HF clock ticks

[AnasIbrahim]

after running for a while ~5 min, I get some crc error (2-5) packets but I'm pretty sure that it's a collision from another source than uses the same frequency and sends a packet once in a while

[AnasIbrahim]

for now the file I make has: number of all packsts recevied, number of packets with crc ok, error rate(crc error/all packets) ex: no_pkts_all,no_pkts_crc_ok,per 199, 199, 0 200, 200, 0 201, 201, 0 201, 201, 0 202, 202, 0 203, 203, 0 204, 204, 0

anything else to add?

[AnasIbrahim]

I tested the star-Hops scenario, initiator( sends to 2 nodes (node 1 & 2) then both send to another one (node 3), where node 3 cannot receive from the initiator.

The packet count should be like: initiator: 0 1 2 node 1 & 2: 1 2 3 node 3: 2 3 4

Sometimes packets from node 3 are received as expected. Fail cases sometimes happen when TX is far away from the RX and the node hangs. Also, I get some weird packet count sometimes but still didn't figure out why.

[AnasIbrahim]

I tested the star connection today. Mostly the packets are as expected, but also a lot of packets are sent and gets a count (not crc error). There is a part of the code that I will reimplement in a better why (what happens when a node gets out of sync because of missing several floods) and Hope that I get rid of these non sense packets.

[AnasIbrahim]

I think we have a full glossy :D .

I made the change we discussed on Wednesday and made a test of 3 non-initiator nodes around the initiator (so just 1-Hop) and everything works fine. The only error I got is when someone placed his laptop and phone around the initiator kit :D. you can check the data on this drive https://drive.google.com/drive/folders/1_JJisPDIa3WXVI6W9IfpiQHd79mstTYN, I will upload everything later to overleaf. So, I think we should meet to discuss other tests and what type of data to collect and how.