-
-
-
-
-
-
I use the Plugable USB dongle on my Windows 7 Pro machine to talk to the Puck with good results. On my RPi2 hub I used this one from ameriDroid (via Amazon) with good results prior to my switching to the RPi3. The RPi3 works well also.
https://www.amazon.com/gp/product/B01LEX8Z6W/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
I got that one since I really wanted to use my Odroid XU4 as my Espruino Hub. And that is the official BT/BLE dongle for it.
-
I found this in one of my old posts. This is the specific syntax I had to use to get my /ble/write to work properly from the linux command line. It has to do with how the linefeed character gets passed through if I recall. But I don't know if this relates at all to the problem @Grzegorz is having.
mosquitto_pub -t /ble/write/c7:6e:71:dd:ee:ff/nus/nus_tx -m $'digitalPulse(LED3, 1, 200);\n'
-
@Gordon I don't think I have seen that particular error before. But from the output it's odd that the service appears to have been translated to its UUID format but the characteristic has not. Maybe there is a subtle problem with the mqtt publish and/or interpretation by the hub.
-
-
@Gordon is it actually possible to request data via the UART? I thought the UART can send a command but there is no way to receive a response. Would love to see a sample code of a UART response.
-
Just that a program I have been running for awhile (days) off and on to toggle a puck from another puck and gather statistics, now just dies on both ends after a few hours. Before I was getting a timout 7 error or something like that on the transmitter after many hours. But a button press would reset the timer in code so it would start up again. On the receiver the connections would continue to succeed but the action, the toggle, would stop. But with 1v91 it all worked well enough at first but then just died and non-responsive. Just sharing experience. Nothing concrete. I think I was on the 1v90.12 on both ends before.
-
It's true that the hub will terminate if it doesn't detect any advertisements for around 10 seconds. The way the code is written if no advertisements are detected the hub assumes something might be wrong so it exits. If you're using the start.sh script in the foreground the hub will then restart. But again, if no advertisements, well you get the picture.
For your other error it looks like the .httpRequest is failing and since there is no rejection handler and no catch you get the Uncaught Error report. If the hub is also exiting there may be a problem there causing the httpRequest to fail in turn.
Lastly, in my experience it's not unusual to have to reset the puck if a ble request fails badly--like if the hub crashed during the request. Sometimes it will become visible again on its own. Like if a timeout expires. But often not.
-
The code I posted here works for me. Post
Essentially defining a service and characteristic on the puck which is what I think you are trying to do. The value from the characteristic can then be read using nRF Connect.
-
@Joakim, Matchstick. Brilliant! I was skeptical at first of @ChristianW 's fingernail trick. But it works great and now that's what I usually do. Too much fun.
-
Interesting that our experiences were so different in virtually the same environment. Only possible difference I see is that I don't think I downloaded a 'minimal' Jesse. I don't recall the link but the image file I downloaded was 2016-11-25-raspbian-jessie.img with a file size of 4,269,056 KB as reported by Win7. I checked my terminal history so I know for sure I did not have to separately install git. The version of node on my working system is v0.10.29
-
-
-
@Gordon, can confirm 70 seconds or so connection time even when the web ide is disconnected. Based on visual feedback from the LEDs. In this mode the lead puck is sending a toggle() to the receiving puck every 5 seconds.
-
Yes! I actually did this [post] and the internal bluetooth and external dongle changed with Zadig are both happy and working properly.
-
@Gordon, yes pretty reliably with that code. I did it just now and I recreated the issue within 60 seconds. I had 2-3 successful saves before the one that failed.
Console:
>save() =undefined BLE Connected, so queueing service update for later Erasing Flash... Disconnected
Here are the results of the peeks after popping the battery and reconnecting:
>peek32(479232) =4294967295 >peek32(479236) =4294967295 >
-
Oh I agree completely. Mostly I am testing to understand some behaviors I am seeing. For example, getPrimaryService in a connect sequence sometimes errors out immediately complaining of a disconnect. That doesn't seem right. So I run long tests trying to gauge how often that actually happens. Then I might change my code a little and run again to see if things improve. Your advertising method makes exceptional sense for your use case.
-
@Gordon should I just send you the file? I think a pull request has to include all the changes for a commit level. Or so I think, I've actually never done a PR. I'm happy to attempt a PR on the full commit. 4 files I think.
The changes to connect.js are more extensive than discovery.js. I don't know what you mean by 'UART specific", except that it is in fact the UART service and characteristic that the code is retrieving. For some reason job.device.discoverAllServicesAndCharacteristics(...) in the original code was not returning for me, so the timeout would always occur, or at least 95% of the time. So I changed the logic to use discoverServices() and discoverCharacteristics() which worked very well. That's the gist of the changes there except I also added a recursive function to write additional chunks of data when the data was more than 20 bytes. Works well! Oh and I fixed the /ble/read topic code which was crashing due to a missing parameter.
-
My multicolor + space gray, + 1 more space gray covers came in this week. Very schnazzy