Receive-only Peer-to-Peer m/xDOT setup

[John VanLaanen]

I have a peer-to-peer application with one control DOT that only transmits and is connected to a PC, and multiple receive-only DOTs in relatively dumb devices. I’d like the receive-only DOTs to power up in serial data mode and just send out all messages that they receive. No talking to these receive-only DOTs required.

I started with the p2p setup that’s in the command reference guide, which worked fine using the devices manually. I then just added AT+SMODE=1, and saved. On the next power-up they do not receive anything. If I reset and manually escape to command mode, then enter an AT+SD, it works fine. Reading the command manual I got hints that this might have something to do with the power management settings, so I experimented.

I ended up settling on using AT+WI=2, AT+WD=2000000000, and AT+WTO=65000. With these additions the read-only dots come up and send out all the received data as desired – most of the time. Maybe there was some operator error on my part when it didn’t work, but these settings have a somewhat unnatural feeling, and this needs to be rock solid.

Is there a better way to accomplish what I need? Any and all suggestions appreciated!

Thanks!!

[John VanLaanen]

Clarification on the terminology I used. I want the receive-only DOTs to send out all radio data they receive on their TX serial lines. No talking to these receive-only DOTs on their RX line required.

Hopefully being a little more explicit helps avoid any misunderstanding of my question…

[Jason Reiss]

Your wake delay setting appears out
of range. I would expect 200-2000, is is measure of ms between wake up and start of data on serial port.

• This reply was modified 6 years, 6 months ago by Jason Reiss.

[John VanLaanen]

Thanks for the reply!

The dot’s power management scheme seems to be all about activity on the dot’s rx pin, which doesn’t match my application at all – I don’t ever want the device to go to sleep if at all possible, and there will never be data on the dot’s rx pin. So my thinking was:

Sleep for WI=2 seconds, wake and wait for WD=2e9 ms (~23 days) for data on the dot’s rx pin (which never happens). Since there is never data on the rx pin, the WT setting doesn’t matter, but I max’d it out to 65000 anyway.

As a result, the device spends 99.9999% of the time awake and able to receive radio data, which is close to 100% as I could figure out how to get using these settings alone. If this is actually how it really works, this would be fine for my application, since it sleeps for 2 seconds just once ever 23 days.

btw – this is not a battery-powered application, and the power consumed by the dot never sleeping is infinitesimal compared to the device it is connected to.

I could dink around with sending a periodic pulse to a wake pin on the dot, but that only wakes the device if it’s sleeping – once awake it still waits for data on the rx pin for as long as the WD setting before going back to sleep again, so I’d still want WD max’d out. All this would accomplish then is to shorten the amount of time it eventually sleeps and get the percentage of time awake slightly higher, but it would never be 100%. Doesn’t seem worth the effort.

[Jason Reiss]

If you want a simple behavior, mbed could be used to create a custom firmware.

[John VanLaanen]

Thanks – understand. Am trying to get something going quickly, and going the MBED route wasn’t my first choice since it seems like this might work. I was trying to determine whether the setup I’m currently using should work predictably and reliably. Is my understanding of how the settings work correct?

Thanks again for responding!!

[Jason Reiss]

Looks like your settings will keep the device awake to Rx packets and output to serial. The device will keep waiting for data on serial. The only thing that breaks the loop is serial data.

If interested have a look at the implementation.

Line 486 for serial mode function.
Line 1308 for Packet Rx event.
https://os.mbed.com/teams/MultiTech/code/Dot-AT-Firmware/file/95c9eb69329a/CommandTerminal/CommandTerminal.cpp

[John VanLaanen]

OK – you’ve confirmed that I’m probably on the right track with the power management settings. However I’ve now definitely confirmed that these settings do NOT always work. My mDOTs frequently power up working in this mode, but not always. I set reset low on the mDOT for about 2 seconds after power is applied, and that reduces the occurrence rate but it still happens a lot (started out at 10mS but that didn’t seem to help much). When it does happen, it always happens on a specific device until I let it sit with power removed for a while. Makes me suspect something is powering up in a bad electrical state and needs all voltages to completely leak off to get reset.

Is the mDOT sensitive to power turn-on slope? Are there any pin states I need to define on power-up (I’m leaving all except resetb floating)? Supply voltage is 3.3V.

Any help is appreciated!!

[John VanLaanen]

Darn it – hold off on the above post. I just noticed something stupid I’m doing on the transmit side that could cause what I’m seeing on the receive side.

[John VanLaanen]

OK – got my stupid stuff on the transmit side cleaned up and I was still seeing the problem of inconsistent receive operation described above. I continued experimenting to try to figure it out, and have landed on issuing a second reset pulse to the DOT a few seconds after the first reset pulse (which is right after power-up). That, so far, seems to have resolved this problem. I have not experimented further to see if only the delayed reset pulse would have worked, or with the duration of the reset pulses (currently 2 seconds each).

Note that the spec says resetb only needs to be asserted for at least 1mS, and I can’t find anywhere where it addresses the timing of the reset pulse after power is applied. This might be something worth addressing in the spec. And, I’m wondering whether starting up in serial data mode in peer-to-peer mode might have different requirements than the normal LORAWAN mode of operation with regard to the timing of reset.

– John

[Author]

Posts