Peer to Peer
- This topic has 8 replies, 2 voices, and was last updated 7 years, 8 months ago by
.
Viewing 9 posts - 1 through 9 (of 9 total)
Viewing 9 posts - 1 through 9 (of 9 total)
- You must be logged in to reply to this topic.
Tagged: #crc_error
Martin Pelletier.
Martin PelletierI got this message on debug mode:
Radio Rx CRC error
Link state 6
Rx error
mdotEvent- Rx error
is someone has an idea how it is generated and how to avoid this??
thx
Mike FioreMartin,
Are you using AT command firmware or building a custom application? What firmware/library version are you using? What mbed-os version are you building against?
Do you see these errors on startup or after attempting LoRa communication?
Cheers,
Mike
Martin PelletierHi Mike,
version 2.0.16 with 5.3.4
building my own program with send(), recv() and sleep(1, mDot::RTC_ALARM, false)
after attempting LoRa communication
is it possible to bypass the CRC? or Checking error in order to send all the time even if something is bad because if the crc error is detected then the next send message will be failed and need to reset the mdot.
In debug mode, i got this:
Radio Rx CRC error
Link state 6
Rx error
mdotEvent- Rx error
Send with tx timeout 5000
Send failed: code 10
Entering sleep (stop) mode 0000037
Send with tx timeout 5000
Send failed: code 10
Entering sleep (stop) mode 0000037
Send with tx timeout 5000
Send failed: code 10
regards,
Martin
Mike FioreMartin,
Assuming based on your info that you’re using rev 80 of libmDot-dev-mbed5. Can you try rolling back to rev 79 or 78? They’re both the same version of library source but use slightly older mbed-os versions.
Cheers,
Mike
Martin PelletierHi Mike,
is it possible to put the mdot just in transmitter (receiver disable)?
I have a better idea why i got the CRC error:
The Rx CRC happens when the mdot sends a message and at the same time it receives another message (as full duplex). After this state, the transmitter sends nothing (send failed) until the receive a good message.
Cheers,
Martin
Mike FioreMartin,
Unfortunately not. Peer-to-peer mode is listening whenever not transmitting.
One thing you could do is sync up the RTCs on your slaves and then assign each device a “slot” for its communication with the master device.
Cheers,
Mike
Martin PelletierHi Mike,
it is possible to sync up all slaves! (it means start at the same RTC) and after gave a slice of time for each slave (the first 100ms for the first and so and so)
do you have any examples? or which function do you take?
best regards
Martin
Mike FioreMartin,
There’s no Dot Library API for any of this – we’re in the application realm now.
You’ll have to send a message to all the slaves (from the master) with the RTC time they should be set to. Or you’ll have to come up with some other way to sync the RTC.
Once that’s done, your slaves should be able to figure out when they should or shouldn’t be transmitting a few different ways:
* poll the RTC (it has a sub-seconds register)
* use the RTC Periodic Wakeup Timer
Full documentation for the RTC is found in the STM32F411RE reference guide.
Hope this helps!
Cheers,
Mike
Martin PelletierHi Mike,
thx for your helps!!
I found a simple manner to sync each slave and give them a time slot where it will be (one – one). Now, the RX error CRC has disappeared.
Hence, we could make multi-slaves to one master, if we manage the sync between them. Otherwise, we could encounter some erratic bug!!!
cheers,
Martin