Hi…again,
After a few days of trying out configurations I can not send anything through LoRa.
The configuration of the PaxCounter device is with SF = 7
On the other hand I have implemented a 1 channel gateway, and I have registered it in TTN. The Gateway is visible from TTN.
The configuration of the Gateway is SF = 7 and listening on channel 1 868300000.
Any idea?
Paxcounter software relies on LMIC stack, and this expects a full LoRaWAN compliant 8ch gateway. Otherwise it won’t work, at least not with tweaks in LMIC stack.
Thanks for the info.
Is there any way to avoid it and be able to transmit through a Gateway own channel?
Some indication to be able to adjust the sending of information by LoRa.
No one stops you tweaking the source code of LMIC stack, but be aware that you then not only own a LoRaWAN specs non-compliant gateway, but also a non-compliant node, and this may affect the used LoRaWAN networks.
So i would recommend you to spend your effort to get a full 8ch gateway. Nowadays this is an invest of not more than $69 if you buy the new TheThingsIndustries Indoor Gateway (“TIG”).
I’m looking for Gateways for that price and those I find exceed $ 250. Could you indicate a link to buy a gateway of the ones you indicate and thus test the system?
Tnaks!
thank you!
I am very interested to apply in any of our projects. I understand that we can configure them to send the information to a server our MQTT, is it possible?
In the project we would like to modify the payload sent the list of the hashes of the Mac and the RSSi, with the aim of being able to analyze, at a tourist level and with some intelligence, distance to the node, waiting time, recurrence, … all applied to mountain routes.
Have you tried the battery life? I have the TTGO T-Beam for the tests. You can indicate the durability of them.
I await news to acquire the Gateway and be able to start the tests.
Thaks a lot.
If you plan to send lots of data like MACs and RSSI it’s not a good idea to use a LoRaWAN network for this. And you should assure that you’re compliant to your countries law if you plan to analyze those privacy data.
Our goal is to send data over long distances due to the lack of WIFI and 4G coverage, that’s why we want to test LoRa.
Since the number of users that are going to be detected simultaneously is not very large, we believe that the estimates would be no larger than 1 Kbyte per minute (the information may be sent every 2-3 minutes). The scan time will be adjusted to 1minute or more.
That kind of configuration is what we want to try.
I suggest you take a look at the limitations for lorawan and Lora regarding time on air, throughput and fair use. Then look at other technologies to send 1K per minute over a large distance.
Concept of paxcounter is to carry out all magics at edge, on the sensor, then send only the result via LoRaWAN network to a server.
If you want just to sniff Wifi MACs and blow all sniffed data on a server, you should use usual commercial systems like Cisco Meraki, Libellium, etc.; but again, be aware that those can be illegal nowadays in many countries, e.g. in EU they may not confirm to GDPR.
Rethink your approach!
New paxcounter Release v1.7.2 is out now:
New feature: DCF77 / IF482 clock controller
How do you enable BLE only mode?
set BLECOUNTER to 1 in paxcounter.conf to enable the compile option.
Build the software and flash it.
When the device has joined, send command 0x0e 0x01 on LoRa FPort 2.
After the device has received the command it enables bluetooth scanning.
There ist currently no command or option to turn Wifi scanning off.
Thank your for the clarification. The doc is suggesting that this option was available and I was looking for it.
I eventually updated one of my ttgov21old board which has been running now for the last 8 months…
It seems all boards need the RTC library now, I had to add in platformio.ini:
@@ -187,6 +187,7 @@ lib_deps =
${common.lib_deps_basic}
${common.lib_deps_lora}
${common.lib_deps_display}
+ ${common.lib_deps_rtc}
build_flags =
${common.build_flags_basic}
upload_protocol = ${common.upload_protocol}
to get it compiled…
Yes, you’re right.
Didn’t see this, because platformio has hold the RTC lib in cache environment.
Let me check…
Fixed it.
Thank your for filing this bug.
I could need some help for debugging the new time sync code in paxcounter. There’s still some weird bug which sometimes occasionally sets a false time after a sync. Can’t find it… 
Apart from this hidden bug the code now achives a precision of +/- 10 milliseconds!
We need a paxcounter right here, inside of this solar box on top of the pole!