I successfully installed and run paxcounter on my TTGO device, smothly running since a few days. Now, after a programming mistake when altering the payload mask (via downlink) I restarted the TTGO and was no more able to reconnect to TTN. The device doesn’t receive a confirmation but repeats trying to connect since hour(s). In my gateway I see a ‘green tick’, so I assume that there was a message coming back from TTN. Any idea what the issue could be and how to solve it? Attached the console screen dumps in case this would be of help to understand the problem. Can it be that there is the download message still ‘hanging’ on a server that wants to react on it?
Propably i have had the same issue some days ago.
Do you remember wich downlink command you send?
Do you have a display on your t-beam?
In my case i deactivated ADR (remote command 07 00) and upon next reboot the device made an join atempt on DR5 (SF7/125kHz) and then switchted to DR7 (!!! FSK: 50 kbps).
In the display FSK was shown inverted (so ADR of worked somehow).
Because there was no real communication with TTN another downlink was not an option to fix this issue.
Furthermore reflashing the device did not fixed it eather. The setting is stored in nvram wich seems to be nonvolatile even during flashing.
I have increased
release_version = 2.0.4
in platformio.ini to clear out the nvram.
Thank you for your reply; in the meantime I really believe it is rather about the config of the TTGO bone than due to TTN issues.
The command I’ve sent was around setting the payload mask (0x14). Instead of submitting a whole byte addressing all elements I just sent only 1 bit set so all the others were set to zero… then I started to play around but made if most probably worse…
As I’m already running 2.0.4 I fear that I cannot upgrade to another version. Do you know if there is any procedure to clear the nvram and to setup the TTGO beam into it’s original status? I’m unfortunately rather a user than an engineer so any help much appreciated! thank you!
You can “upgrade” the version
Just type 2.0.5 (or try 2.0.4.1) in the line.
The configmanager assumes that the stored values are invalid, because thei are from an outdatet version.
Hello! Many thanks for your valuable input, this sorted out the whole mess. However, after having seen the TTGO on the TTN console couldn’t manage to get BLE scanning reactived. No, after various trials I re-installed a complete fresh set of software in the Platformio environment (under Visual Studio) I can no more restart the TTGO as it always reboots and reboots and reboots… Would be very happy and graceful in case someone knows a good trick like it was provided from ‘engelkin’ today… Thanks a lot in advance.
I am not sure what “a new set of software” might be.
But perhaps i can help you again with my personal experiences.
This bootloop scenario is well know for me when certain hardware is not or not proper connected but configured.
As i use several T-Beam (with and without display) it is quite commen with new releases that i forget to comment out the “#has display” Option.
This results in a bootloop as you described.
Not using the right hal file is a similar error.
I suggest you to take some time and slowly read through the readme.md and check the necessary configuration step by step.
Make the basic settings in the first step. Upload it and check the result.
Then try to make small changes.Nothing is more time consuming than changing to much and finding mistakes afterwards.
You try to get BLE scanning working.
The basic configuration is made in paxcounter.conf with the line: #define BLECOUNTER 1 // set to 0 if you do not want to install the BLE sniffer
But perhaps it is something diffrent you miss (Display output / Lorawan Payload)?
Thank you again so much!!! I reinstalled each and everything, started the project from scratch including Visual Studio/PIO and now everything is working again. Phantastic to have people like you that just provide support to technical juniors… May I just ask another dumb question: with downlink cmd 0x11 and 0x12 you can trigger an alarm when the pax counter identifies on Wifi a pre-defined MAC address. Is there anybody that could share an example on how to structure the two downlink messages as an example (sent by the TTN console)? I just want to avoid to have again broken my whole running environment. Many thanks again!!!
Give me some time to test it myself and track it down in the code.
Perhabs there is someone with experience with this feature and can answer this question faster.
Quick answer:
A uplink on port 2 with the payload 12 01 A4 C1 38 27 5F 7A seems to work to register the beacon number 1 with MAC adress A4:C1:38:27:5F:7A .
18:23:22.179 > [I][lorawan.cpp:509] myRxCallback(): Received 8 byte(s) of payload on port 2
18:23:22.179 > [I][rcommand.cpp:174] set_beacon(): Remote command: set beacon ID#1
You need to send Again on Port2 the Payload 11 01to active the alert.
This is described as following:
0x11 set beacon proximity alarm mode on/off
0 = Beacon monitor mode off [default]
1 = Beacon monitor mode on, enables proximity alarm if test beacons are seen
0x12 set or reset a beacon MAC for proximity alarm
byte 1 = beacon ID (0..255)
bytes 2..7 = beacon MAC with 6 digits (e.g. MAC 80:ab:00:01:02:03 -> 0x80ab00010203)
That’s fantastic, man! I just activated the beacon with the TTN console and the commands (0x11 and 0x12), stored my iPhone MAC address on the paxcounter and switched the phone off. After having switched it on again I got a message on port 6 with the beacon number and the RSSI value. Thank you so much for this coaching, much appreciated!
First of all it is time to change the topic!
We are far away from connection issues.
“TTGO -T-Beam paxcounter connection and configuration” would suite better.
As far as i can see there is no such mechanism in the code.
Probably this is not the way the beacon alert is intended to work.
The use case of BLE beacons does vary a lot. For example in a manner of indoor navigation the deativation of the alert is not necessary.
Thank you Sir! I read the data coming from TTGO beam now with Node Red and introduced a de-bouncing function. Just found out that only when the RSSI threshold is too low the bouncing takes place. But important to say, many thanks again for this incredible support what is of infinite value for me!
Thanks a lot in advance.