Wifi/BLE Paxcounter Project with ESP32 boards


(Frasanc1) #344

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!


(Verkehrsrot) #345

(Frasanc1) #346

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.


(Verkehrsrot) #347

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.


(Frasanc1) #348

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.


(Jac Kersing) #349

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.


(Verkehrsrot) #350

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!


(Verkehrsrot) #351

New paxcounter Release v1.7.2 is out now:

New feature: DCF77 / IF482 clock controller


(Nalberto) #352

How do you enable BLE only mode?


(Verkehrsrot) #353

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.


(Nalberto) #354

Thank your for the clarification. The doc is suggesting that this option was available and I was looking for it.


(Amedee) #355

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…


(Verkehrsrot) #356

Yes, you’re right.
Didn’t see this, because platformio has hold the RTC lib in cache environment.
Let me check…


(Verkehrsrot) #357

Fixed it.
Thank your for filing this bug.


(Verkehrsrot) #358

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… :frowning:

Apart from this hidden bug the code now achives a precision of +/- 10 milliseconds!


(Verkehrsrot) #359

We need a paxcounter right here, inside of this solar box on top of the pole!IMG_20190215_110958


(Amedee) #360

The license header does not encourage collaboration :roll_eyes:


(Jeff Uk) #361

@Amedee @Verkehrsrot Not looked at the algorithm in detail and its not clear just what/where the patent is claim for but there is a huge amount of prior art in this area and doesn’t look to be anything ‘novel’ involved IMHO. Suggest the developer(s) look to what else is available in market for prior art before spending lots on patent attorneys.

Given this is in context of LoRa/LoRaWAN system they could do worse than by starting with looking at Semtech’s own synchronisation & timing product portforlio and methods :wink: (IEEE-1588v2, Network time-synching (‘real-time’ Enet, Sonet, SDH,Cellular, GPS PPS timing distn, etc) and additional application work in e.g. timesynching UHD-SDI/SMPT Video systems/genlock etc. where ping-pong/offset time adjustments (TDM & PTP) have been practical and demonstrate long before this LoRa/Paxcounter effort kicked off))…BTW, RichL and his team, though now largely focused on LoRa/Collos ecosystem enabling cut their teeth on this sector going back >decade…just saying :slight_smile:

GIYF = ‘Semtech’ ‘TopSync’ ‘SETS’


(Verkehrsrot) #362

Thanks for this hints, and, no doubt, there is lots of prior art in this field.
But it’s not the intention of the patent holder (it’s not a manufacturer) to protect a time synching mechanism. Intention is to prevent that others (probably manufacturer) file a patent for this regarding a specific use case, to keep a certain niche market open.


#363

Cool. Let’s ask BVG guys. Next BVG hackathon in Berlin will be in May 2019! Interesting! So they can manage crowd movements…