Most recent activity
-
Puck.js firmware can be built for SDK14 which does support Bluetooth 5, but it hasn't been tested enough so far, and in this case I don't think it will help you.
The longer range is achieved just by slowing down the transmission speed, not by boosting the power in any way - but then I believe the slower transmission is only readable by bluetooth 5 devices, and not any older ones.
What device are you using to read the advertising data? It may be that something with a better aerial will give you significantly better range.
Also, have you tried
NRF.setTxPower(4)- which will increase the transmission power. -
Hi - please can you post in a new thread and I'll try and help out there? @tbd's connection problems don't seem related at all other than that he used 1v99?
-
On the Pico and WiFi boards, the actual VBat pin in the STM32F4 is connected straight to VDD - I'm afraid there is no easy way to power just that and not VDD as well.
There are schematics available (linked from the Pico/WiFi pages) so you could potentially cut the track and wire up VBAT separately - but it would be very difficult
However you might find that entering the proper standby mode of STM32 gives you the power requirements you need. It's probably around 2 uA vs 1 uA for vbat mode - by comparison the MCP1703T voltage regulator on board draws 2 uA, so you're not going to see a massive difference in overall consumption between the two modes.
-
This would actually be a really neat use for a Pixl.js (or just a Puck/MDBT42 with a display attached). You could actually display some historical data to give you some idea how things were going, and could then just leave it by the side.
-
The self-test does come up green though?
If you did end up connecting a high voltage to
D29I guess that could have caused problems. You could try shortingD29toGND, which would ensure that if it was working at all it wouldn't auto-initialise the serial port. That should help with battery usage.However the bad connection may be related to the corrosion. If you search for the device with your laptop (or the Web Bluetooth screen) do you see a high signal strength - or is it quite low compared to the other Puck.js?
-
So the Pucks would be static and transmitting advertisements, and the smartphone would receive them to find out its location?
You'd definitely get some usable location information - but honestly you'd have to try. The accuracy would depend on what distance it is over and whether there are obstacles in the way. It definitely won't be accurate down to the centimeter though!
-
What you're doing looks ok - but you're doing this from an interrupt?
It's likely that what is happening is Espruino does something like a garbage collection pass outside of an interrupt (very occasionally), but then if your interrupt happens while that is running, it may not be able to get data reliably and so might break.
Usually that's ok (apart from lost data), but if you're printing data at a high IRQ level and then the output buffer gets full, you can get deadlocked.
If you're on the Nucleo then I guess you could run a debugger and find out what/where the error occurred.
However when implementing Bluetooth I decided a while back that allocating JS variables in interrupts just wasn't working reliably. Especially as it looks like you're only sending chunks of 11 bytes I'd just define a static buffer, write the data to that in an IRQ, and then handle that in an 'idle' handler.
... or Bluetooth support actually writes data into the input buffer (eg. https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c#L211) but I think that's overkill for what you want here.
-
You're not really supposed to re-use UUIDs for different things, so the Bluetooth SIG suggests you should use a totally random 128 bit UUID (the chances of duplicates and then basically nothing).
So, go to a site like this and get a random UUID - for instance:
123fd926-40c3-4cf3-9797-9a8703e32795Then just change the second group of 4 for all your services and characteristics, eg:
123f0001-40c3-4cf3-9797-9a8703e32795 123f0002-40c3-4cf3-9797-9a8703e32795 123f0003-40c3-4cf3-9797-9a8703e32795 123f0004-40c3-4cf3-9797-9a8703e32795So then you have:
NRF.setServices({ "123f0001-40c3-4cf3-9797-9a8703e32795": { "123f0002-40c3-4cf3-9797-9a8703e32795": { notify: true, value : [Math.round(E.getTemperature())], } } }); setInterval(function () { NRF.updateServices({ "123f0001-40c3-4cf3-9797-9a8703e32795": { "123f0002-40c3-4cf3-9797-9a8703e32795": { value : [Math.round(E.getTemperature())], notify: true } } }); }, 1000);And you're sorted.
The only gotcha is advertising 128bit UUIDs is hard since they use up a lot of your available space for advertising - so honestly I'd avoid that and would instead try to find your device based on its name (which you can easily change).
-
Just to add, the docs for
setServicesare here: http://www.espruino.com/Reference#l_NRF_setServicesNeither
readnorwritein your example above are valid, so that probably explains why at least0x2902isn't readable.
intervalis the the number of milliseconds between the advertising packets getting sent. The default is 375ms.Basically in order to do anything with a Bluetooth LE device, you have to get an advertising packet. The device sends a packet and the listens for a very short time after that - and if there's a connection attempt it needs to be sent during that time.
The advertising packets are sent on 3 different frequencies in rotation. If a device is listening for connection then in usually only listens on 1 frequency - so even at 375ms the advertisement will probably only be received once a second. Most computers will only wait around 2 seconds to get a connection, so higher intervals get progressively more hit and miss for establishing connections.
If I could have set it any lower and got reliable connections, I would have (in fact early Pucks shipped advertising slightly less often and I had to change it).
Basically:
If you really want to save battery more then you can lower the advertising interval and then have code that raises it back up to 375 when there's a button press.