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!
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!
The license header does not encourage collaboration
@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 (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
GIYF = ‘Semtech’ ‘TopSync’ ‘SETS’
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.
Cool. Let’s ask BVG guys. Next BVG hackathon in Berlin will be in May 2019! Interesting! So they can manage crowd movements…