search

cyberman54 / ESP32-Paxcounter

Wifi & BLE driven passenger flow metering with cheap ESP32 boards
https://cyberman54.github.io/ESP32-Paxcounter/
Other
1.69k stars 397 forks source link

Problem with remote control #738

Closed rdmueller closed 3 years ago

rdmueller commented 3 years ago

Thanx for the paxcounter! It is a great device but I need some help getting this up and running...

The paxcounter works on my heltec v2 board and reports its valuse, however, I can't get the remote control as described here https://github.com/cyberman54/ESP32-Paxcounter#remote-control to work.

I managedto send a 0x09 0x00 on port 2 and reset the device. However, if I send a command like 83 86, I expect to see a new message with some detailed data, but there is no such message.

What could be wrong?

cyberman54 commented 3 years ago

Battery monitoring (0x83) is not functional on heltec v2, due to a conflict between ADC2 and Wifi, see note in heltecv2.h file. Time request (0x86) should work, are you sure that you sent 0x86 to the device, not 86? What do you see in serial log, if you increase log level to 4 and send the remote command?

rdmueller commented 3 years ago

thanx. searial log is quite a good idea.

and yes, I typed "86" (and other numbers) instead of "0x86" - that's what the ttn interface expects.

btw: regardings the time - it also seems that it does not sync the time. I have

#define TIME_SYNC_LORAWAN               1       // set to 1 to use LORA network as time source, 0 means off [default = 1]

and even

#define TIME_SYNC_COMPILEDATE           1

but the time displayed remains 1970...

rdmueller commented 3 years ago

I now got some logs

17:11:51.328 > [W][timesync.cpp:236] timesync_serverAnswer(): [23.660] Network did not answer time request
17:11:51.338 > [W][timesync.cpp:108] timesync_processReq(): [23.661] Timesync aborted: handshake out of sync
17:11:51.346 > [I][lorawan.cpp:436] myRxCallback(): Received 1 byte(s) of payload on port 2
17:11:51.355 > [I][rcommand.cpp:345] get_time(): Remote command: get time
17:11:51.359 > [W][lorawan.cpp:320] lora_enqueuedata(): LORA sendqueue is full
17:11:51.561 > [I][lorawan.cpp:214] lora_send(): 2 byte(s) sent to LORA
17:11:52.839 > [I][senddata.cpp:117] sendData(): Counter cleared
17:11:52.845 > [W][lorawan.cpp:320] lora_enqueuedata(): LORA sendqueue is full
17:11:54.837 > [W][lorawan.cpp:320] lora_enqueuedata(): LORA sendqueue is full
17:11:54.845 > [I][senddata.cpp:117] sendData(): Counter cleared

I now search for the size of the sendqueue :-)

rdmueller commented 3 years ago

hm. I always get the error message about the sendqueue...

cyberman54 commented 3 years ago

It seems you have some hickups in your setup:

rdmueller commented 3 years ago

a) that explains why I get no timesync. But it now should use the compile time, shouldn't it? b) hm. my TTIG is max 10m away. What are the software parameters I could change to fix this?

cyberman54 commented 3 years ago

is it a heltecv2, as you stated first, or a TTIG (which model)?

rdmueller commented 3 years ago

it is a heltecv2 with which I currently test. Sorry, with TTIG, I wanted to reference the TheThingsIndoorGateway (https://www.thethingsnetwork.org/docs/gateways/thethingsindoor/index.html)

rdmueller commented 3 years ago

I think I found a problem - the send rate was once too high. Could it be that just reprogramming the device with new parameters is not enough to lower the send rate? I now reset the device and it seems to be better.

rdmueller commented 3 years ago

yeah! I now get responses to the remote control commands! Thanx for your help and patience... Now, there is only the open question for me, how to ensure that changed parameters are send to the board...

cyberman54 commented 3 years ago

use rcommand 0x20 to store parameters.

rdmueller commented 3 years ago

but I don't want to store the parameters - I want to overwrite them with my new configuration. I expect that, when I re-configure my code and thus the configuration, this new config will be used when I upload the code to the device...

cyberman54 commented 3 years ago

This sounds like a support request, not an issue. Could you please move this to Discussions? Thanks.

cyberman54 commented 3 years ago

@rdmueller fyi: in current master a workaround was added to get battery voltage value on Heltec V2 boards (using ADC2).

rdmueller commented 3 years ago

thanx! then I will give this a try!

rdmueller commented 3 years ago

hope that this workaround works for the changed gpio pin 😁

cyberman54 commented 3 years ago

Not sure if the patch grabbed really works...

rdmueller commented 3 years ago

at least it does not work for my board. the heltec sample.code for measuring the bat level with gpio 37 works, but the paxcounter with heltecv21.h only shows "no batt"

cyberman54 commented 3 years ago

try heltecv2.h