nrf24 autoack slaves with same address

Projects Networking, Protocols, and Devices
181

notsolowki:
EDIT:....Besides this line i messed up, i think this i correct...
bool success = writeTo('T', &cmd, cmd.setData('M', "*pet me"), false);

You are wrong.

Why do you think you should send a command for node 'M' to the ack pipe of 'T'?

notsolowki:
I'm sorry about that I dont even know what that control panel file is. i cant even open it. my keyboard is so far away from my computer it must have not copied what i wanted.

Strange, in a couple of ways.

You now have a quite complete example for most infos you have given,
if you manage to specify exactly what you want to send and receive in the different nodes
we could extend it to cover all possibilities.
The dosing count up and count down variables don't make any sense to me,
Please explain those to me. I miss the list of commands for that node too.

The main command line interface fed by Command allows you to controll any node remotely,
all local commands can also be invoked with a packet, given the command length is below 27 chars.

182

Whandall:
You are wrong.

Why do you think you should send a command for node 'M' to the ack pipe of 'T'?
Strange, in a couple of ways.

You now have a quite complete example for most infos you have given,
if you manage to specify exactly what you want to send and receive in the different nodes
we could extend it to cover all possibilities.
The dosing count up and count down variables don't make any sense to me,
Please explain those to me. I miss the list of commands for that node too.

The main command line interface fed by Command allows you to controll any node remotely,
all local commands can also be invoked with a packet, given the command length is below 27 chars.

Okay, bool success = writeTo('T', &cmd, cmd.setData('T', "*pet me"), false);

the dose count is to count how many times the dose up or dose down cycles have completed. when the code activates the dose up then count ++1 for dose up, same for dose down. and then these set dose time which sets a variable to time is ms for the pump to run. those are the only 3.

So the first to is the targets actual address and the second to is just for refrence in the packet?

 if (incomingCommand == phIsLow) {
      doseUpOnMarker = millis();
      phUPState = 1;
      doseUpCounter ++;
    }

if (phUPState == 1) {
  digitalWrite(dosingPump1, HIGH);
  if (millis() - doseUpOnMarker > dosingParams.doseUpTime1) {
    digitalWrite(dosingPump1, LOW);
    phUPState  = 0;
  }
}
183

How can i send a command to the timer from the control panel to change the time of a timer? I cant seem to make it work from the serial consoles

184

You are lazy.

How do the commands s or S do their job? whine sends a command too.

I guess each dose-node has one uint32_t count and two uint32_t times?

the dose count is to count how many times the dose up or dose down cycles have completed.

So it is always one up cycle followed by one down cycle?
Why do you want to count both then?

when the code activates the dose up then count ++1 for dose up

Which code activates and how is that different from counting?

same for dose down.

It must be activated and counts after finishing?

and then these set dose time which sets a variable to time is ms for the pump to run. those are the only 3.

These are what? The commands to set up/down times? Which should be?
A time sets a variable? There is only one pump? Which three? Commands?

You need to be a lot more specific and clear.

I see a 'go up/down' 'setTime up/down' in my crystal ball.

The outside will have no idea what the state of the system is with that information.
idle? up dose? down dose? pump? But who cares.

It's hard to get specifications from you.

BTW what are the ranges of the times/count? How do you want to handle power failures?

notsolowki:
So the first to is the targets actual address and the second to is just for refrence in the packet?

The first is the physical, the second the logical target address.
To be a valid command, both have to match the receiving targets personal address.
So you can send any comand to any node,
but it's a little harder to send commands to nodes that should not honor them.
It should not be possible to control nodes without using their node id physically and logically

185

I guess each dose-node has one uint32_t count and two uint32_t times?
each has 1 for doseUPcount and doseDOWNcount.

So it is always one up cycle followed by one down cycle?
Why do you want to count both then?

i count them to be sure i dont have any bugs causing the dose pumps to keep cycling when i didnt expect them to, the pumps handle highly corrosive chemicals that can cause major problems. so i like the counter so i can tell whats going on. its either dose up or dose down in no specific order. the counter should be incremented after the end of the dose cycle

These are what? The commands to set up/down times? Which should be?
A time sets a variable? There is only one pump? Which three? Commands?

there are 2 pumps each has its own independent runTime in the range of ms,
id like to be able to set the runTimes from the control panel.

I see a 'go up/down' 'setTime up/down' in my crystal ball.

yea that's pretty much it

The outside will have no idea what the state of the system is with that information.
idle? up dose? down dose? pump? But who cares.
i would like the dose pump modules to broadcast their counter to the control panel without ack. i want the commands sent from the control panel ack. in the end i will be collecting all this information on the multicast pipe and displying it on an lcd screen and other processing

It's hard to get specifications from you.

BTW what are the ranges of the times/count? How do you want to handle power failures?
i will have power failures handled by storing the on times and other variable in the EEPROM.

I had sent a command STt1g and it works. but the timer code is not updating the control panel to let me know timer 1 is on

this is basically the whole program for the dose,

const int dosingPump1 = 4; //2.2k ohm
const int dosingPump2 = 5;

float phIsHigh = 123.123;
float phIsLow = 321.321;

unsigned long respondDelay2 = 0;

unsigned long doseUpCounter = 0;
unsigned long doseDownCounter = 0;

unsigned long doseDownOnMarker = 0;
unsigned long doseUpOnMarker = 0;

int phUPState  = 0;
int phDOWNState  = 0;

unsigned long doseDownTime1 = 1700;
unsigned long doseUpTime1 = 1700;



void setup() {
  Serial.begin(57600);
  Serial.println("hello");
  pinMode(dosingPump1, OUTPUT);
  pinMode(dosingPump2, OUTPUT);
}

void loop() {

  if (phDOWNState == 1) {
    digitalWrite(dosingPump2, HIGH);
    if (millis() - doseDownOnMarker > doseDownTime1) {
      digitalWrite(dosingPump2, LOW);
      phDOWNState = 0;
      doseDownCounter++;
    }
  }

  if (phUPState == 1) {
    digitalWrite(dosingPump1, HIGH);
    if (millis() - doseUpOnMarker > doseUpTime1) {
      digitalWrite(dosingPump1, LOW);
      phUPState  = 0;
      doseUpCounter++;
    }
  }
}

im sorry the ranges of timer count should be the same unsigned long integer

186

Can you explain your logic behind the update flag?

187

notsolowki:
Can you explain your logic behind the update flag?

Absolutely, there is no update flag, so there is no logic behind it.

188

Whandall:
Absolutely, there is no update flag.

Can you explain to me exactly why U is in the status? or whatever it is. i dont understand why its there why did you use it?

Right now on the timer module i have whine set to off. On the control panel i have whine and announce set to off. The timer is announcing to the control panel and it all looks good. now i need the control panel to update its local variable to that of the incoming ones.

189

It is called updated flag.

What does updated mean to you?

The flag gets set, if you have changed the data.

How would you determine that and which parameters have changed and which timer needs adjustment?

The flag could be reset after honoring the changes in the Timer node or after an announcement.

190

Whandall:
It is called updated flag.

What does updated mean to you?

The flag gets set, if you have changed the data.

How would you determine that and which parameters have changed and which timer needs adjustment?

It must have some importance i just dont understand yet, at what point is it cleared? in my old program i received the variables from the incoming data strait into variables. it was bad that way. sometimes they would get garbled and display the wrong value for a second. What should i do next.

I my old code i sent a mesage to the timer with the new time command followed by the new time. then the nrf24 would send the value of the variable i used to hold the time value. over and over. the master would receive the message and reverse the order

191

You have to somehow synchronize/introduce the changes that you make via Serial or via received commands.

That happens absolutely asynchronous to the timers operation,
so the updated flag gives observers of the announce a chance to see what was changed
and it allows the timer node to focus on changes and does not force it to chack all parameters for
possible changes.

Again, how would you determine which parameters - if any - were changed by a command?

You will probably don't have access to the code that parses the input to inject a changed value
directly into the right working variables, so how would you handle the situation if you detect the
successful operation of a command changing the timers parameters?

192

Whandall:
Again, how would you determine which parameters - if any - were changed by a command?

You will probably don't have access to the code that parses the input to inject a changed value
directly into the right working variables, so how would you handle the situation if you detect the
successful operation of a command changing the timers parameters?

i would probably do it the wrong way. In my old code i would send the command and rely on the lcd to show me the value sent back to the control panel. If it didnt happen successfully i would send it again. and this is because i couldnt think of what else to do. it was buggy that way and the values sometimes would display incorrect for short periods of time. I like how your doing things i just want to understand it too lol

193

On control panel i change this part of the code is this right?

  if (radio.available(&pipe)) {
    byte len = radio.getDynamicPayloadSize();
    radio.read(incomingData, len);
    if (showMulticast || pipe == 1) {
      printPipeAndLen(pipe, len);
      Command* cData = (Command*)incomingData;
      switch (*incomingData) {
        case 'T':
          if (pipe == 2 && incomingData[1] == *functionalAddress) {
            tInfos.setFrom((TimerInfos*)cData);
            ((TimerInfos*)cData)->disp(compressed);
            tInfos.disp(compressed);
          } else {
            ((TimerInfos*)cData)->disp(compressed);
          }

now the values on the control panel reflect the ones on the timer?

Here is some console output from the control panel,

T * M a 0:123,321 1:123,4 2:5,6 3:123,321
<2-24 T * T k 0U:123,321 1:123,4 2:5,6 3:123,321
T * M a 0:123,321 1:123,4 2:5,6 3:123,321
<2-24 T * T l 0U:123,321 1:123,4 2:5,6 3:123,321
T * M a 0:123,321 1:123,4 2:5,6 3:123,321
<2-24 T * T m 0U:123,321 1:123,4 2:5,6 3:123,321
T * M a 0:123,321 1:123,4 2:5,6 3:123,321

194

Divide et ipera.
Make small functions that work together, don't create big monolithic sketches.

The parsing of the data could (should) be a function of the object,
this has to communicate with other parts of the program
here for instance the code that really manages the action.

So I thought flagging at least the affected timer(s) would make life easier,
as I already mentioned it could be extended to show all changed attributes individually,
not only on a "something of this timer was changed" base.

notsolowki:
On control panel i change this part of the code is this right?

Why do you want to have a local TimerInfos object?
That is not needed for printing or displaying.
And you will generate updated flags for the difference between the incoming and local TimerInfos,
not the changes that occured in the observed Timer-node.

195

Whandall:
Divide et ipera.

So I thought flagging at least the affected timer(s) would make life easier,
as I already mentioned it could be extended to show all changed attributes individually,
not only on a "something of this timer was changed" base.
Why do you want to have a local TimerInfos object?
That is not needed for printing or displaying.

I just duplicated the code you posted for the time over to the control panel. i turned off announce and whine on the control panel and changed the addresses. i dont know what else to do now. also why does this say to T to * from T
<2-24 T * T l 0U:123,321 1:123,4 2:5,6 3:123,321

196

Why do you want to have a local TimerInfos object?
That is not needed for printing or displaying.
And you will generate updated flags for the difference between the incoming and local TimerInfos,
not the changes that occured in the observed Timer-node.

197

Why do you want to have a local TimerInfos object?
//
That is not needed for printing or displaying.
Do you mean in the control panel code. I didnt want to delete anything because i didnt want to butcher the code. do you mean the structure TimeInfos?
or here?,

       } else {
           ((TimerInfos*)cData)->disp(compressed);
         }
         break;
       case 'R':
         ((TimerInfo*)cData)->disp(compressed);
         break;

or here,

TimerInfos tInfos(*personalAddress); //probably not

Or here,?

     case 'T':-
         if (pipe == 2 && incomingData[1] == *functionalAddress) {
           tInfos.setFrom((TimerInfos*)cData);
           ((TimerInfos*)cData)->disp(compressed);
           tInfos.disp(compressed);
         } else {

And you will generate updated flags for the difference between the incoming and local TimerInfos,
not the changes that occured in the observed Timer-node.
//
I don't quite understand what your trying to tell me here.

198

There is no reason for the existance of tInfos in the control panel unless you give good reason for that.

And that would be?

199

Whandall:
The is no reason for the existance of tInfos in the control panel unless you give good reason for that.

And that would be?

I didn't want to delete anything and have you upset with me any more than you are. Iv'e been waiting for instructions from you.

200

Should i delete every instance of tinfos from the control panel sketch? The only reason i think it would be there is to hold the values of the timers