[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

[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 – 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]

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!!

[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.

[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…

[Author]

Posts