I'm not able to compile that sketch for a Micro, the code is much too big,
what configuration is missing?
Der Sketch verwendet 51158 Bytes (178%) des Programmspeicherplatzes.
Das Maximum sind 28672 Bytes.
text section exceeds available space in board
Globale Variablen verwenden 1584 Bytes (61%) des dynamischen Speichers,
976 Bytes für lokale Variablen verbleiben.
Das Maximum sind 2560 Bytes.
`I would guess you posted the ESP32 sketch, why?
Hi,
Thank you for keeping this thread "alive".
One of the problems with a long posts is that there is a lot of information in it.
The hardware description was given in post #12 and in post #22 photo because you asked me to provide information about the hardware.
I started using an Arduino proMicro in the receptor, but it was too slow.
A lot of receiveing problems happened because the Arduino was busy displaying the value of the variables most of the time.
So, after the project was working for about 2-3 months, I changed the receptor micro to ESP32.
I thought the hanging/non-transmitting sketch was one of the transmitters running on a Micro.
If I can not see the code, I can not offer much help.
Hi,
I think I made the things more confused.
The micro that is "freezing" is an arduino proMicro.
The code used in this this micro is copied in post #12 and starts with ****TRANSMITTER 2 *** (THIS ONE FREEZES FROM TIME TO TIME).
Thank you again for your patience and time.
I have no interest in picking code out of the post.
Hi,
Maybe my english is not good, I am sorry for that.
What I was trying to say is that the code used by the micro is posted in this post in conversation marked as #12.
I should also clarify that when I say "freezes" the only function that has stopped working is the nRF24L01 data transmission/reception.
The micro keeps reading sensons data and displaying it correctly.
The receiver keeps displaying the data received from transmitter #1, but the data relative to transmitter #2 is "frozen" .
On the receiver time there is a section of the code that identifies if no data has been received by any of the two transmitters in a 5 min time. If that happens, ESP32 turns on an alarm led.
The code in #12 does not compile, and gives a crap about failing sends.
You are using quite some RAM (1854 (72%) 706 remaining),
without any buffers that the Network layer will allocate and use.
It should be enough, but you could free more
by using F() to put constant strings in prints to PROGMEM.
As an example, change Serial.print(" nCurrThruResistorPP= "); to
Serial.print(F(" nCurrThruResistorPP= ")); and free 23 bytes of RAM.
This works for lcd.print(); likewise.
//********Read level from DP sensor************
rawDp = analogRead(dpPort);
delay (1000);
You delay loop for a second, and expect the Network layer to work?
payload_t payload = { packets_sent++, Irms, flowRateLPM, Pdisch, DpFilter, Pinlet, lampCurrent, rawDp, flapState }; // Create a variable with the above structure
Your wishfull thinking does not help, this will only initialize the payload structure,
so all of your messages were always 1 packet sent and zero values, not so useful.
And the
//??? radio.setRetries(15,15); // (delay, count) added on rev 5 disbled,needs setAutoAck = true
radio.setAutoAck(false); // active on rev 3 April 2023
cripples the packet layer, and is very counterproductive.
Hi,
Thank you for getting involved again.
Some comments:
1 - the code for transmitter 2 copiled without errors in my machine (see below)
2-[quote="Whandall, post:48, topic:1119080"]
Your wishfull thinking does not help, this will only initialize the payload structure,
[/quote]
the code is able to send the value of the variables correctly. It has been operating for more than one year.
I may have messed the code while "cleaning up" it before posting. I will load it to my bech test setup later and send you a video of the results.
Anyway, would you please explain the correct way of doing it?
3 - [quote="Whandall, post:48, topic:1119080"]
You delay loop for a second, and expect the Network layer to work?
[/quote]
Why would the Network fail? Would you please explain?
I have seen many examples where people send sensor info every minute or more.
Also, as I said it works (but eventualy the Network freezes...)
4 - I will do some search about this Serial.print(F....) command use it in every instance of the code.
Regards,
Roger
I am enclosing a copy of the Serial.print debug data below, so I can understand better the comment about initialization ONLY of the variables in the data structure.
As we can see, payloal.val1 to ...val9 are not zero.
This values were not actual sensor readings (they are not installed), just noise picked up by the Arduino inputs that do not have pull up/pull down resistor connected to them.
++++++++++++++Output values++++++++++++++++++++++++++++++
rawDp= 139
% Level= 49
Irms= 4.77
rawPdisch= 181
Pdisch= 0.63
voltageRatio1= 0.17
DpFilter= 150.75
voltageRatio2= 0.50
P_Inlet= 519.66
Lamp Current 0.09
****************Lamp current*************************************
nVPP= 0.80
nCurrThruResistorPP= 0.80
nCurrThruResistorRMS= 0.00
lampCurrent= 0.08
****************Send Payload*************************************
val1= 4.80
val2= 0.00
val3= 0.63
val4= 150.75
val5= 519.66
val7= 0.08
val8= 139
val9= 0
---------------OptFlowrate Values------------------------
currentMillis = 83229
currentFlowSensorPulseCount = 0
flowRateLPM = 0.00
totalFlowSensorPulseCount = 0
TotalLiters = 0.00
Copy the code from the post and try again, the following line does not make the compiler happy.
I have no idea, whether that junk was added, or replaced something,
after removing it, the code compiles.
Not with the provided code, that can only send a constant packet.
Two possibilities are:
payload.Irms = Irms;payload.Irms = emon1.calcIrms(1480);Once a second is not regularly enough.
//***********Pump the network regularly*********************
network.update();
This structure needs to be packed on the ESP32 side, or you will see junk values for val8.
The current comment is wrong (check by printing sizeof(payload_t)).
The size is legal, but leads to fragmentation.
As we can see, you print the values of the variables, not the content of your payload.
if (serialPrintFlag == HIGH)
{
Serial.println("****************Send Payload*************************************");
Serial.print(" val1= ");
Serial.println(Irms);
Serial.print(" val2= ");
Serial.println(flowRateLPM);
Serial.print(" val3= ");
Serial.println(Pdisch);
Serial.print(" val4= ");
Serial.println(DpFilter);
Serial.print(" val5= ");
Serial.println(Pinlet);
Serial.print(" val7= ");
Serial.println(lampCurrent);
Serial.print(" val8= ");
Serial.println(rawDp);
Serial.print(" val9= ");
Serial.println(flapState);
}
There is no magical transfer by initializing it once from the real variables.
Hi,
Yhank you for your reply.
I am really embarassed about it. I had in my mind that I was printing payload.val1.. val9.
I have fried one or more modules of by bench test setup, so I will need some time to reassembly them to test the "revised code".
I would like, if possible, if you could expand on the "remaining issues":
1 - How to properly code the package ackwoldge function of the RF24Network library ( I had to drop it down because I could not make it work)
2 - What is the suggested value, if any, of a delay used after an analogRead instruction.
If I recall correcltly, I had to add it so the values read are correct, but it was an issue of the very early versions of the code and maybe it is no longer necessary.
3- How to deal properly with the packet fragmentation issue?
The code currently does not use the first varible of the structure (counter) which uses 4 bytes.
Will it help if I remove it from the structure?
thanks
If your sending nodes can reach the receiver directly, there is no need for the Network layer,
which solves the fragmentation problem, because the packed structure is below 32 byte.
Your code gets simpler, and you gain more control.
Remember to pack the structure on the ESP32 side
(It does not hurt to add that on the AVR side, but it is not needed)
If rapid reading of an analog port messes with the read values,
something is going on, that requires more attention, than a delay.
Your structure can contain functions, which is quite handy.
struct __attribute__ ((packed)) payload_t // 32 bytes max, used=7*4+2+1 =31 bytes OK! revised March 2023
{
uint32_t counter; // number of packets transmitted 4-bytes
float Irms ; // - 4 bytes
float flowRateLPM; // - 4 bytes
float Pdisch; // - 4 bytes
float DpFilter; // - 4 bytes
float Pinlet; // - 4 bytes **added in rev4
float lampCurrent; // - 4 bytes ** added March 2021
int16_t rawDp; // - 2 bytes
boolean flapstate; // - 1 byte
void setValuesAndIncrement(
float _Irms, float _flowRateLPM, float _Pdisch,
float _DpFilter, float _Pinlet, float _lampCurrent,
int16_t _rawDp, bool _flapState)
{
Irms = _Irms;
flowRateLPM = _flowRateLPM;
Pdisch = _Pdisch;
DpFilter = _DpFilter;
Pinlet = _Pinlet;
lampCurrent = lampCurrent;
rawDp = _rawDp;
flapState = _flapState;
counter++;
}
void display() {
Serial.print(F("counter= "));
Serial.println(counter);
Serial.print(F("Irms= "));
Serial.println(Irms);
Serial.print(F("flowRateLPM "));
Serial.println(flowRateLPM);
Serial.print(F("Pdisch"));
Serial.println(Pdisch);
Serial.print(F("DpFilter= "));
Serial.println(DpFilter);
Serial.print(F("P_Inlet= "));
Serial.println(Pinlet);
Serial.print(F("Lamp Current "));
Serial.println(lampCurrent);
Serial.print(F("flapstate= "));
Serial.println(flapstate);
}
} payload;
Initialization could look like
// Address of the other node
const uint8_t other_node[] = ">Base";
radio.begin();
radio.setPALevel(RF24_PA_MAX) ;
radio.setDataRate(RF24_250KBPS);
radio.setRetries(3, 15); // (delay, count)
radio.openWritingPipe(other_node);
radio.stopListening();
Sending could look like
void sendPayload()
{
if (serialPrintFlag == HIGH) {
payload.display();
}
bool ok = radio.write(&payload, sizeof(payload));
called from
payload.setValuesAndIncrement(Irms, flowRateLPM, Pdisch, DpFilter, Pinlet, lampCurrent, rawDp, flapState);
sendPayload();
Hi,
Thnk you very much again for your help.
As soon as I rebuild my test rig I will implement these changes on the code and let it run for a day o two to test it.
I read the TMRh20 library docs again and I could not get how it is possible to have two nodes and not use the RF24Network as you are saying since the beginning.
Would you please explain how to do it?
Regards,
Roger
You have a simple one target, two senders scenario,
with (data) packets only transmitted one way.
To distinguish the different senders, it would be wise to put some identification in the packet,
you have one byte free, so you could use that.
Apart from the differently initialized identification field, the code for senders is just the same.
So I have just to use the RF24 library instead of the RF24Network and delete the header instruction?
I would advise not to use the network layer,
which means all network layer stuff should go.
Give it a try, and post that.
Thank you very much for the help.
I finally managed to get the test setup running again but have another question before editing the code:
The "real world variables" that the sensors are reading move very slow.
They are levels, flowrates, and electric currents (these should be almost constant and are monitored just to detect system failures).
I have seen two different approaches used to send the data in this case:
a- keep sending the data as frequent as possible in both transmitters;
b- since data varies slowly, there is no point in "overload" the channel with data since it may cause problems on the receptor side.
Use a non blocking timer on each transmitter to send the data at "large intervals" eg. 1min.
In my installation, one transmitter is located 100m from the receiver while the other only 20m.
Also, there are some shrubs between the farthest antenna and the receptor.
I have tried to conpensate for that by using a high gain directional antenna on this tramsmitter.
I don't know if the distance and the obstacles are causing the reception failure and why this failure is corrected when a second receiver (in direct view of the Tx antenna) is turned on.
Consideing the above cenario, what approach should I use in the code: a or b?
regards,
Roger
Neither a nor b. I would send the data around once a second.
That makes more sense if both stations have the PA+LNA, not only the transmitter,
the handshake has to go in the other direction.