is this using explicit or implicit?

[dudmuck]

I was able to receive these signals on sx1276 in implicit header mode, but not explicit mode.
It appears to send a longer packet when I put a message into the chat box, which would imply explicit mode. (implicit mode is fixed-length)

[guruofquality]

The decode/encoder blocks are really not worked out yet to match existing hardware. The code order and interleaving is not quite in the same bit order, so I'm not sure you would properly decode anything. Curious.

[Allen-tao]

How to measure the bit error rate（BER） of Lora-SDR? I want to test the stability of Lora-SDR under different power noise.

[AlphaRne]

Hi, I did a fork with support for the actual hardware (SX1272).
This includes different interleaver, whitening and checksum algorithms.
https://github.com/AlphaRne/LoRa-SDR

[guruofquality]

@AlphaRne thats super awesome, cant wait to give it a test!

[guruofquality]

@AlphaRne I checked out the fork, looks pretty good! I was trying to get a decoder configuration that received from my RN2483. Theoretically this should work with the 1.0.0 firmware if the receiver is SX1272 compatible, so I will keep messing around with it. But basically after some testing, I would like to merge the work and drop the "legacy" encoder stuff altogether. And expand the unit test across a larger matrix of the encoder/decoder settings :-)

[guruofquality]

@AlphaRne I was trying to get the encoder->decoder loopback to pass. I added some prints and shank the size of the test generator packets to demonstrate:

This is the output of the PothosUtil test command from this test branch:

PothosUtil --self-test1 /lora/tests/test_encoder_to_decoder
Testing /lora/tests/test_encoder_to_decoder...
Testing SF 7
  with CR 4/4
30, 9, 249, 218, 145, 81, 4, 76, 1, 121, 0, 0, 
packetLength 10
dataLength 15
_hdr 0
_explicit 1
dOfs 3
30, 9, 249, 218, 17, 17, 52, 88, 1, 121, 181, 151, 0, 0, 0, 0, 0, 0, 
verifyTestPlan
Exception: Pothos::Testing LoRaTest.cpp:138
  Unexpected error after last checkpoint
  Proxy Exception Message: Assertion violation: CollectorSink::verifyTestPlan(): packet0 -- CollectorSink::verifyTestPlan(): Value check for element 4: expected 145 -> actual 17

So I went ahead and created an exhaustive test of the hamming SX* functions. There are failures so there may be an implementation issue.

[AlphaRne]

@guruofquality Thanks for testing it all,
I fixed the hamming functions, the parity bits weren't masked from the output
and there was one false bit in the check matrix.
I did put it in my repo as I don't have write access to this one.

It still gives me some error on the encoder->decoder test and I will play around some more.

[AlphaRne]

@guruofquality I fixed the decoder bugs and the tests run fine here now.

[guruofquality]

Cool. I made some more progress based off that work with the loopback unit test on this branch (PothosUtil --self-test1=/lora/tests/test_loopback). It looks like there was an issue with the SNR calculation (the average was a total summation actually).

[9600]

@AlphaRne you should hopefully have received an invitation to become a collaborator, giving you write access.

[AlphaRne]

@guruofquality The variable naming for the power stuff may not have been the best.
I thought of the SNR as a measure of the signal power to the total noise power of the frame.
It is reported like that from the actual hardware with the values going negative if the signal is hidden inside the noise.
Using the average per bin power as reference will give the CNR.
Maybe both should be exported.

[guruofquality]

@AlphaRne Sorry for the delay! so I was getting the unit tests working and I wanted to double check some changes.

The SNR

The variable naming for the power stuff may not have been the best.
I thought of the SNR as a measure of the signal power to the total noise power of the frame.
It is reported like that from the actual hardware with the values going negative if the signal is hidden inside the noise.
Using the average per bin power as reference will give the CNR.
Maybe both should be exported.

The name was bad, and thats my fault. Basically, the threshold scaling changed and I was having issues with the unit test. I think SNR sounds better, I will fix the scaling.

Modulator insertion
Also, I commented out this code for the loopback test. Basically it makes the modulator always output something even when there is no input packet. I'm curious about the reason and should be conditionalize this to keep it around, like was this for self-testing?

I have an open issue for dead-time insertion for simulation with bursty modulators. I wonder if this is the reason: pothosware/PothosComms#21

if (not this->input(0)->hasMessage()) {
+               //for (i = 0; i < N; i++){
+                   //samps[i] = 0;
+               //}
+               //outPort->produce(i);