How do I get multiple different mock barometers?

[rmtucker]

@NeverDie

Here is a little sketch that compiles on the NRF5.

// Enable debug prints to serial monitor
//#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_NRF5_ESB

/**
   @def MY_NRF5_ESB_PA_LEVEL
   @brief Default nRF5 PA level. Override in sketch if needed.

   - NRF5_PA_MIN = -40dBm
   - NRF5_PA_LOW = -16dBm
   - NRF5_PA_HIGH = 0dBm
   - NRF5_PA_MAX = 4dBm
*/
#define MY_NRF5_ESB_PA_LEVEL (NRF5_PA_MAX)

#define MY_NRF5_ESB_CHANNEL (76)

#define MY_NRF5_ESB_MODE (NRF5_250KBPS)

#define MY_NODE_ID 10
#define VOLTAGE     0
#include <MySensors.h>

float vcc = (hwCPUVoltage() / 1000.0);

MyMessage VoltageMsg(VOLTAGE, V_VOLTAGE);

void presentation()
{
  sendSketchInfo("General sensor", "1.0");
  present(VOLTAGE, S_MULTIMETER);
}


void setup() {
//  Serial.begin(115200);
//  while (!Serial) ; // wait for Arduino Serial Monitor
}

void loop() {
  send(VoltageMsg.set(vcc, 3));
//  Serial.print(F("Voltage = "));
//  Serial.print(vcc, 3);
//  Serial.println(F("v"));
  sleep(60000);
}

[NeverDie]

@gohan said in How do I get multiple different mock barometers?:

@NeverDie said in How do I get multiple different mock barometers?:

I have it working now, but why are:

#define LONG_WAIT 500
#define SHORT_WAIT 50

needed?

I think those are used in the code to delay the sending of mock values

Yes, but why? Is it to give the serial gateway time to process it?

I'd like to know the motivation for it because I'm using an ESP8266 as my serial gateway (the Easy-Peasy), and it's considerably faster than, say, an Arduino UNO. For instance, maybe it doesn't need these delays on the sending side to keep up.

[gohan]

I think it's more related to allow enough time for people to read the log without flooding it

[NeverDie]

@gohan said in How do I get multiple different mock barometers?:

I think it's more related to allow enough time for people to read the log without flooding it

LOL. Glad I asked!

[NeverDie]

@gohan said in How do I get multiple different mock barometers?:

I think it's more related to allow enough time for people to read the log without flooding it

No, there's more going on than just that apparently. If I reduce their value to zero, it bombs. Reducing short-wait to zero causes the mote to get stuck in a loop somewhere, and reducing long-wait to zero causes the gateway to miss receiving some packets.

If these examples are meant to teach, it sure would be nice if it was documented code!

[gohan]

It is always good practice not to flood the gateway anyway :)

[rejoe2]

This wait() can also help to avoid packet losses due to insufficient power supply when using nRF24.

[mfalkvidd]

@NeverDie I am not sure, but I think the mock sketch is meant only for validating new builds of MySensors (by the Jenkins build system connected to Github). It is not included on the build page and as you said it is not documented so I don't think it is meant to teach.

I may be wrong though, I didn't know that sketch existed before you mentioned it.

At almost 1,500 lines it is 10x bigger than most of the build examples, which seems like a very bad idea if the intention is to teach.

[gohan]

It's big because it has all the code to simulate almost all sensors 😀

[mfalkvidd]

@gohan yes. And that is a terrible way to teach.

[gohan]

all-in :D

[NeverDie]

@rejoe2 said in How do I get multiple different mock barometers?:

This wait() can also help to avoid packet losses due to insufficient power supply when using nRF24.

You mean it needs extra time for the auxiliary cap to recharge? If so, surely we can find a better way to power the radio module that doesn't require taking a breather between packets....

I don't remember how it works with the nRF24L01, but on the RFM69, there's only one buffer for both sending and receiving, so you have to empty the receive buffer before you either send or receive another packet.

[mfalkvidd]

@NeverDie a discussion on that topic is underway in https://github.com/mysensors/MySensors/issues/892

[NeverDie]

@mfalkvidd
In that case the nRF52832 should be faster at emptying the buffer, since it doesn't have to rely on the slower SPI bus. And from what I gather, it can also do DMA's, which could speed things up even further.

[mfalkvidd]

@NeverDie for a node I think the bottleneck is the speed of the air transfer. Sending a message takes about 1ms at the default setting of 250kbps. But a busy gateway might benefit from the higher processing speeds on nRF52832.

[NeverDie]

@mfalkvidd said in How do I get multiple different mock barometers?:

@NeverDie for a node I think the bottleneck is the speed of the air transfer. Sending a message takes about 1ms at the default setting of 250kbps. But a busy gateway might benefit from the higher processing speeds on nRF52832.

Does it default to 250kbps to compensate for the range problems that the nRF24L01 has? I'm planning to bump mine up to 2mbps if at all possible. That might save appreciably on battery life.

[NeverDie]

I suppose the

wait(long_wait)

isn't so bad a power drain if it's actually sleeping rather than busy-waiting for 500ms.

[NeverDie]

@rmtucker said in How do I get multiple different mock barometers?:

#define MY_NRF5_ESB_PA_LEVEL (NRF5_PA_MAX)

#define MY_NRF5_ESB_CHANNEL (76)

#define MY_NRF5_ESB_MODE (NRF5_250KBPS)

Just now noticing that your definitions:

#define MY_NRF5_ESB_PA_LEVEL (NRF5_PA_MAX)

#define MY_NRF5_ESB_CHANNEL (76)

#define MY_NRF5_ESB_MODE (NRF5_250KBPS)

can also be set in myconfig.h.

Strangely, myconfig.h defaults to max Tx power on the nrf52, but not max Tx power on the nrf24. Not sure why, especially since, if anything, the nRF24 needs it more.

So, I just now changed myconfig.h to put everything at max Tx power and 2mbps ota datarate. A lot of the nrf24 fake chips don't even run at 250kbps.

[gohan]

Do mean the fake chips need to run at higher datarate?

[rmtucker]

@NeverDie
Ye i just like all the settings at the beginning of my sketches etc,it reminds me if i have changed channel number etc.