Improve on random()

[WereCatf]

The original code doesn't check for what mode the radio is in and
returns 0, if the radio isn't in listening-mode; this code-change
waits until any queued packets have been transmitted, checks the
current mode, changes it to listening-mode, gets the random value
and then proceeds to change the mode back to whatever it was.

[torntrousers]

Does it need a yield() call in this loop so the WDT doesn't fire on platforms like ESP8266/32?

[WereCatf]

The loop shouldn't take that long. Did you try it, then, and it crashed?

…

On 26. syyskuuta 2018 12.00.20 Anthony Elder ***@***.***> wrote: @torntrousers commented on this pull request. In src/LoRa.cpp: > @@ -582,7 +582,26 @@ void LoRaClass::setOCP(uint8_t mA) byte > LoRaClass::random() { - return readRegister(REG_RSSI_WIDEBAND); + uint8_t currMode = readRegister(REG_OP_MODE); + uint8_t retVal = 0; + + while(isTransmitting()); Does it need a yield() call in this loop so the WDT doesn't fire on platforms like ESP8266/32? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[torntrousers]

The loop shouldn't take that long. Did you try it, then, and it crashed?

No I haven't tried it, just use ESP's a lot so wary of loops like this. It could take a bit of time to transmit bigger packets at high spreading factor / low bandwidth though.

[WereCatf]

Well, I suppose. I guess adding a yield() in there wouldn't hurt anyone.

[ricaun]

I guess is a bad idea make the random function to change the module to receive mode.
I use to generate a randomSeed on setup() and use the default random.

LoRa.receive();
// Generate a random seed with 32 bits
uint32_t seed = (uint32_t) LoRa.random() << 24 |
                (uint32_t) LoRa.random() << 16 |
                (uint32_t) LoRa.random() << 8 |
                (uint32_t) LoRa.random();
randomSeed(seed);

Check the exemple.
https://github.com/ricaun/arduino-LoRa/blob/master/examples/LoRaSimpleRandomSeed/LoRaSimpleRandomSeed.ino

[WereCatf]

I guess is a bad idea make the random function to change the module to receive mode.

Is a bad idea why?

[ricaun]

Is a bad idea why?

Because of this while(isTransmitting()) yield(); and why a random function need to be so complex.
For a small code is ok, but when you have a more complex code, blocking the main code is a bad design. Could break others existents codes.
I know you want to improve the library, I want too.
But I don't see why change...
It's my opinion but not my library so...
👍

[WereCatf]

But I don't see why change...

Personally, I believe that a function with such a simple premise as returning a random byte should be as self-contained as possible. There's no good reason for why the user should have to bother messing with setting correct modes for the LoRa-chip for a one-off function-call with no long-term functionality.

Yes, my approach means that each call to random() takes longer than it originally did, but on the other hand, it makes the function a truly one-off thing, just as e.g. the C++ rand() is -- you call it when you need it and that's all there is to it.

If sandeepmistry doesn't approve of this approach then fine, I'll close the pull-request and just stick to my own fork, but until then I shall disagree with you.

[ricaun]

Personally, I believe that a function with such a simple premise as returning a random byte should be as self-contained as possible. There's no good reason for why the user should have to bother messing with setting correct modes for the LoRa-chip for a one-off function-call with no long-term functionality.

I like your point, you are right.

If sandeepmistry doesn't approve of this approach then fine, I'll close the pull-request and just stick to my own fork, but until then I shall disagree with you.

No worries, I guess I prefer low-level functions.

[morganrallen]

I'm generally oppose to these kinds of checks, since this PR was originally submit, 'support' has been added for the 1310 board(sorry this hasn't got attention...) and doesn't even begin to handle many other boards out there. Can this check instead be performed against _onReceive itself?

[IoTThinks]

Pardon my silly question, why we ever need to have a random() function for LoRa?
Is there any specific case for this random() in LoRa applications?

"Generate a random byte, based on the Wideband RSSI measurement."
byte b = LoRa.random();

Thanks a lot.

[WereCatf]

Pardon my silly question, why we ever need to have a random() function for LoRa?
Is there any specific case for this random() in LoRa applications?

"Generate a random byte, based on the Wideband RSSI measurement."
byte b = LoRa.random();

Thanks a lot.

It's not that LoRa needs it, it's that it allows one to have a way of generating more-or-less truly random values since those values are generated from all the random noise the radio picks up. The Arduino random() isn't truly random.

This is to say that it's just a useful addition one can use, if they wish to, but they don't need to use it nor does the library itself need it.