German IT developer who found his long lost love for electronics and connected devices...
Most recent activity
Sure. Thanks. I'm already refactoring some of the code.
So I can post the old code or spend some time to get the new sorted.
One single puck advertising full blast will cause about 20-30 events / second on the receiver side.
Having all eight pucks together will process about 115-130 events / second.
Currently it is hard to trigger the error message. It just happened at some time while testing the device "in the field".
The error was actually both
Execution Interrupted (multiple times) and also
Execution Interrupted during event processing
The BLE connection was quite slow and laggy at that point.
Yes, it's the one with the aerial. For some reasons:
- I'd like to experiment with reception ranges, maybe put the antenna "on the track" (there should be a gap in the track) or use a directional antenna.
- I wanted bigger batteries since I fear the Pixls coin cell will die at some time when scanning for hours, flashing lights and beeping
- I had a box for everything like buttons, batteries, power switch etc. anyway, so why sacrifice a Pixl?
setScan handler may be an issue indeed. If I monitor ~ 8 devices for longer somehow the thing freezes and when I connect via BLE afterwards I'll see messages like
Interrupted during event processing coming up. Is this related?
The crux is:
- I'd need to process every single packed received since there may not be many when someone passes very quickly
- I'd do some calculation / thresholds / decision if this was a lap or not, so there are some lines of code involved here. Still looking for a reliable and also simple solution. Maybe you haven an idea.
First it worked on the assumption that contact is lost for some seconds on the far side of the lap so the next time someone passes it counts a new lap.
But if someone stays just at the edge of reception or is veeery slow, this can accumulate many false laps.
So now I monitor RSSI which will have to rise above a certain level first and then drop again below another level. Will have to test this again.
Or maybe I'll make
setScan just do basic things and fill a buffer or something and do the calculations in another concurrent task?
Since I have collected a number of Puck.js devices and some MDBT42s there is the current need to improvise a cycle track lap counter for some 2..8 riders on a 250 m cycle track.
The project has progressed beyond POC now, what I do is:
- let the pucks just advertise with frequency cranked up to the max and mounted to the bikes
- have the MDBT42 scanning (bigger battery here, so no worries) at the start/finish line
- whenever a puck comes in range, monitor RSSI and count a lap right after RSSI has maxed out (probably after RSSI either drops significantly or connection is lost completely). I assume the connection is lost at the far end of the track anyway (~ 100 m), otherwise I have to adjust the external antenna to a lower gain model
- have the MDBT42 track/queue each id + lap timestamp and advertise this as a service to be pulled and visualized by a laptop via Web Bluetooth (this is a todo).
Simple tests were very promising. I will have to check if passing at 50-60 km/h at 5-8 m distance carrying 8 Pucks all advertising will work flawlessly just to be sure...
Question here (I am not so much into the internals/Espruino architecture):
I connected a Pixl display to the MDBT42. Will additional load through interfacing/drawing or doing other calculations decrease the receive rates from received Pucks or will BTLE scanning always have priority (like interrupt handling)?
I have the feeling the sensors are crap. Some of them seem to work for a few weeks or more, but others drain their battery within hours or sometimes minutes.
I have no idea why and even bought another two sets of sensor to rule out a bad batch.
Maybe it's because I use them in a unusually high pressure range of 6 to 8 Bar.
Or maybe there is something in the protocol that I did not get and they rely on some handshake by the original app...
@user126998 can you confirm anything of my observations or are yours just working fine?
After testing for a few weeks there were issues with the battery life. In the beginning sensors worked for days without noticeable battery wear.
Then some other sensors started failing after only 1-2 days, eating batteries like candy.
I bought another (identical) set and tested indoors with a modified aluminium water bottle and all was fine. Once the sensors were installed on the wheels some of them also started to drain battery.
Taking the first set indoors again and counting messages showed that some sensors (the ones with the battery issues) sent far more messages than the others.
I don't know if this is a hardware issue or if there is more about the protocol than I first thought.
But how can they run dry when there is not a smartphone around? This is probably the case in 90% of the time...
I just ordered a different/updated version (BLE 5.0) now and have a look at their protocol and battery lifetime. The outer caps just look similar. Stay tuned...
Ah yes, @Gordon thanks for mentioning. But I feared to run short of GPIO pins in this future project... ;-)
And for those who wonder (and asked) - there was an eBay link at the top of that thread already: https://www.ebay.co.uk/itm/122179960272 - looks like the baby version of the Pixl.js display.
The display also has a backlight. It seems to be a bit "whiter" than the one of Pixl.js.
And it runs on 3.3 V - the 5 V rating of the eBay listing probably only refers to the backlight (which runs off a GPIO pin as well in my case).