Fix Random function

[sabas1080]

Hi everyone

I am doing this pull request based in the work of @Kongduino in the issue #394

Welcome feedback

Thanks

[wero1414]

Just add some minor changes, to allow the example to compile in any board

[sabas1080]

Thanks @wero1414 , I have made the changes

[wero1414]

@morganrallen @sandeepmistry this seems to fix the problems with getting random numbers with the radio, could you check it out?

It would close the #150 PR and also the issue #394

[sabas1080]

ready @wero1414 @tobozo

[Kongduino]

I will do some tests, but we need to remember that the LoRa chip must be set in a specific state (continuous receive, SF 7, BW 125 KHz, C/R 4/5) before reading register 0x2c. We need to warn the user, and possibly provide a way to switch ti the proper settings, and then switch back to the user's preferred settings.

[Kongduino]

See https://github.com/Kongduino/ESP32_Random_Test for an example. This version of LoRandom.h seamlessly sets up LoRa for rng, and resets LoRa to the previous settings when done.

[Kongduino]

Thanks @wero1414 , I have made the changes

There was a reason (not that important but still) to put the settings in binary: these registers have several settings within a byte, so the binary representation helps seeing what is set up.

Example:

  writeRegister(RegOpMode, 0b10001101);
  // MODE_LONG_RANGE_MODE 0b1xxxxxxx || LowFrequencyModeOn 0bxxxx1xxx || MODE_RX_CONTINUOUS 0bxxxxx101

[sandeepmistry]

Hi @sabas1080, thanks for opening this pull request!

I've made some comments to start some discussions. @wero1414 @Kongduino @tobozo feel free to participate in the discussion as well.

[tobozo]

Speculation :

Use a double buffer random pool with implicit update, when the first buffer is consumed it is marked as such and updated on next opportunity. Both buffers are filled when LoRa.begin() is called, and can be separately re-filled by the driver when marked as consumed.

Benefits:

• Lora.random() actually acts as initially expected with reduced communication overhead (bonus backwards compat).
• New features to manipulate randomness (buffer size, pool size).

[Kongduino]

LoRa.setPins(SS, RFM_RST, RFM_DIO0);

This is specific to a board, BastWAN, that I used originally to create LoRandom. This should definitely be removed from the example code...

[sabas1080]

I'm coming back to finish this task

[IoTThinks]

Hi,
How is the new method continuousRxMode related to the RX_CONTINOUS mode in receive() metthod?
Will the receive() use continuousRxMode?
Thanks a lot.

[sandeepmistry]

@sabas1080 any thoughts on @IoTThinks comment in #395 (comment)?

[plybrd]

@IoTThinks comment in #395 (comment)

Hi,
How is the new method continuousRxMode related to the RX_CONTINOUS mode in receive() metthod?
Will the receive() use continuousRxMode?
Thanks a lot.

void LoRaClass::continuousMode()
{
  writeRegister(REG_OP_MODE, 0x72); // -> 0b10001101
}

writeRegister(REG_OP_MODE, MODE_LONG_RANGE_MODE | MODE_RX_CONTINUOUS); // -> 0b10000101

There is an description how to generate random numbers in Application Note AN1200.24 from Semtech.
See Chapter 4 of Random Number Generation for Cryptography. It said for RegOpMode:
Bit 7 -> 1
Bit 2-0 -> 101
Nothing is said about Bit 3

Datasheet says: REGOpMode Bit 3 LowFrequencyModeOn, after Reset it is set to 1. But the setting is only important for access to some registers for FSK/OOK Mode.

Is it not much more clear what is going on by writing

writeRegister(REG_OP_MODE, MODE_LONG_RANGE_MODE | MODE_RX_CONTINUOUS);

[plybrd]

Hi,
there are many application which needs only few random bytes. A big buffer of random bytes is nice only for applications which needs much of them.
Switching between sending/receiving and generating random numbers should work on the fly.

Why not start by adding just a function
byte LoRaClass::random(uint8_t *buffer, size_t size)
which gives the user just how many bytes he needs and sets the register back to the state before calling this function?

For later on this function can be used to fill some buffer or double buffer of random bytes, ...(see #395 (comment)).