-
-
Hi @Gordon, gave that a try, still getting 10 meters at best, outside in open space. I changed the code to this so I didn't need to reconnect each time, it just flashes an LED if it sees another Puck
setWatch(function() { LED1.set(); NRF.sleep(); NRF.findDevices(function(devices) { LED1.reset(); devices.forEach(function (device) { if (device.name && device.name.indexOf('Puck.js') >= 0) { digitalPulse(LED3,1,[1000,1000,1000,1000,1000]); } }); NRF.wake(); }, 4000); }, BTN, { edge:"rising",debounce:50,repeat:true });
Any further ideas?
-
@Gordon Hmm. I'm using
NRF.findDevices(function(devices) { console.log(devices); }, 1000);
but I'm barely getting 10 meters range, let alone 80!
Flashed firmware to both devices, did NRF.setTxPower(4) on both devices.... just not getting any sort of range.
Any ideas?
-
Well I'm not trying to track through walls or anything, just in a very large space. 1500m2. However thats 30m x 50m.
Now my brain gets confused because geometry was never a strong suit (oh yes I'm looking forward to the triangulation maths), because in theory that means a single puck (with 50m range) could cover the entire space? Or am I mad?
-
@Gordon btw, what is the rough maximum ranges (rx, tx) of the bluetooth module in Puck?
-
I think I like both approaches. Problem with RPZ-W's is, everywhere that sells them is one per customer and I need at least 3 for triangulation!
Good to know its plausible.
Are you still on 2 day shipping on Tindie? I'm gonna need a few Puck's ASAP. I want to order direct but if somewhere else ships faster it'll have to be them.
-
I'm looking for a solution to tracking people as they move around in a space and I'm wondering if attaching some Pucks to the people will give me something workable.
I'm guessing I can use some form of triangulation based on signal strength if I set up some Pucks around the space as well?
Has anyone had any experience doing this sort of thing? @Gordon know anybody that has achieved this, or if it is even possible given the capabilities of the Puck?
I'd need to be able to differentiate between two people standing within a couple of feet of each other.
-
-
-
-
That seems to fix it!
Its worth noting that this drops the maximum baud rate that seems reliable.
I used to get
3000000
as a workable baud, but now with that I'm getting82 bytes
87ffc3ffff00c0f9000001fdff0003ffff0003feff00f0fc0067005Af500027c78f0e500ffff00
+I
16892 so farin the received data, I guess the +IPD isn't complete so Espruino gets confused.
I'll try and find a slower (but higher than 115200!) baud that is stable.
-
So this whole debacle is at least mostly my fault. A while ago I had to reflash the ESP8266 firmware and ended up with 0.50 AT command set, which as we discussed here: http://forum.espruino.com/conversations/304736/?offset=25#13630588 has a longer boot preamble than the 0.40 command set, which seems to confuse the FIFO buffer and therefore the standard EspruinoWiFi module.
To work around it I've been doing my own hack to reset the ESP8266 and then hand over control to the EspruinoWiFi module.
What I didn't realise is that this causes two
.on('data')
event handlers to be registered (my one is never freed), and this causes many, many, many issues further down the stack. It also explains why everything WiFi has been so slow, the data event handler is being run twice for everything!@Gordon as I am stuck with having to use my workaround to boot the 0.50 firmware, could you possibly provide a
disconnect
function in the AT library to release the event handlers?var wifi; function onInit() { var doPreambleReset = true; wifi = require("EspruinoWiFi"); var connectGetIPAndFetchData = function() { wifi.connect(WIFI_NAME, { password : WIFI_KEY }, function(err) { if (err) { console.log("Connection error: "+err); return; } console.log("Connected!"); wifi.getIP(function(err,ip) { console.log("IP address is: "+ip.ip); var http = require("http"); var fetched = 0; http.get("http://www.espruino.com/press/logo_square_blur.png", function(res) { res.on('data', function(data) { fetched += data.length; console.log("Got "+data.length+" bytes"); console.log(fetched + ' bytes so far'); }); res.on('close', function() { console.log("Closed"); console.log(fetched + ' bytes total'); }); }); }); }); }; if (doPreambleReset) { initWifi(connectGetIPAndFetchData); } else { connectGetIPAndFetchData(); } } /* Perform a manual reset of the WiFi chip, sometimes the preamble from a hardware reboot * exceeds the FIFO and confuses EspruinoWiFi module. If we do a software reboot, * the preamble is smaller. */ function initWifi(callback) { digitalWrite(A14, 0); Serial2.setup(115200, { rx: A3, tx : A2 }); /* Herein lies the problem. The AT module has a 'connect' function, but no 'disconnect' * In the 'connect' function it registers an event handler on the 'data' event of the * Serial port, and this never gets released. When we use EspruinoWiFi.connect later, * this registers a second event handler, and this causes something to screw up. */ at = require('AT').connect(Serial2); at.cmd('\r\nAT+RST\r\n', 10000, function(data) { setTimeout(callback, 10); }); digitalWrite(A13, 1); digitalWrite(A14, 1); }
-
-
Oh now this is interesting.
Here's what I get when I use your code with all the rest of my stuff deleted:
8 bytes
125 bytes
73 bytes
70 bytes
69 bytes
69 bytes
69 bytes
69 bytes
69 bytes
69 bytes
68 bytes
69 bytes
69 bytes
69 bytes
69 bytes
69 bytes
69 bytes
68 bytes
69 bytes
69 bytes
55 bytes
109 bytes
72 bytes
69 bytes(fairly consistent 69byte chunks).
With my code:
9 bytes
383 bytes
26 bytes
188 bytes
302 bytes
383 bytes
26 bytes
369 bytes
25 bytes
142 bytes
209 bytes
333 bytes
383 bytes
26 bytes(fairly consistent 300+ byte chunks).
If I add some extra logging:
383 bytes
20042 so far
30 bytes
20425 so far
383 bytes
20455 so far
30 bytes
20838 so far
383 bytes
20868 so far
31 bytes
21251 so far
383 bytes
21282 so far
31 bytes
21665 so far
383 bytes
21696 so far
31 bytes
22079 so far
383 bytes
22110 so far
271 bytes
22493 so far
9 bytes
22764 so far
4 bytes
22773 so far(mine crashes around here)
yours happily cruises along:
74 bytes
25212 so far
74 bytes
25286 so far
60 bytes
25360 so far
115 bytes
25420 so far
77 bytes
25535 so far
75 bytes
25612 so far
74 bytes
25687 so far
74 bytes
25761 so far
74 bytes
25835 so far
74 bytes
25909 so far
74 bytes
25983 so far
74 bytes
26057 so far
74 bytes
26131 so farSo the question becomes, why does my code fetch larger chunks? I don't think I've configured anything to specifically ask for larger chunks...
I've just added the flow control code to your example and I still get 69byte chunks, so its not the flow control.
-
While I imagine it probably won't make a difference, could you try it going the other way? Download rather than upload. Doesn't need to be a huge file, 40-50kb should do the trick... maybe just try and download https://www.espruino.com/press/logo_square_blur.png ?
-
-
To be honest, the OOM error has mostly been replaced by the power issue, I can't actually replicate the OOM any more.
I did a setInterval to print the memory usage and it never really drops too low.
{ "free": 3775, "usage": 3373, "total": 7148, "history": 0,
"stackEndAddress": 536990532, "flash_start": 134217728, "flash_binary_end": 435488, "flash_code_start": 134283264, "flash_length": 524288 }
{ "free": 4146, "usage": 3002, "total": 7148, "history": 0,
"stackEndAddress": 536990532, "flash_start": 134217728, "flash_binary_end": 435488, "flash_code_start": 134283264, "flash_length": 524288 }
{ "free": 4144, "usage": 3004, "total": 7148, "history": 0, -
-
Yes I see the resets on the USB-TTL.
I've gone back to using the pipe() we were discussing in the other thread that lead to memory issues.
I thought the ESP was minimum 3v? http://www.electrodragon.com/w/ESP-12F_ESP8266_Wifi_Board
I'm going to try hooking my components to an entirely seperate power supply, currently my voltage regulator is powered by the 5v output of the espruino (which I assume is just the 5v line from USB), so perhaps it is drawing too much from there and browning out the onboard vreg.
I will note, that quite often I experience an issue where I can't flash to the Espruino once something has gone wrong with the WiFi. I usually have to disconnect power and reflash, I wonder if this is a symptom of the STM32 browning out?
-
-
I've tried several different cables and I'm now running from an externally powered USB hub to make sure I've got enough juice going to the Espruino.
I've hooked up a USB-TTL directly to the ESP8266 so I can try and sniff things without having the Espruino log them, and something is definitely up:
+IPD,0,1412:f4b2<snip>1f6ff00f0 ERROR +IPD,0,5840:fc<snip>001
and then I can also see the resets happen as well.
I tried looking through the schematics, but its not my strong suit. If I supply 3v3 to the board I'm guessing I have to unplug the usb beforehand otherwise I let out the magic smoke?
Also do you have a capacitor between VCC and GND on the ESP8266? I can't see one on the schematic but I might just be missing it.
-
After a fairly extensive debugging session, I've finally produced the following error message:
ets Jan 8 2013,rst cause:1, boot mode:(3,6)
load 0x40100000, len 23620, room 16
tail 4which I believe means the ESP8266 has browned out and reset itself due to lack of power.
Cut down version of the code:
http.request(httpOptions, function(requestResult) { requestResult.on('data', function(data) { digitalWrite(A15,1); // FC Close console.log(data); var written = f.write(data); f.skip(written); digitalWrite(A15,0); // FC Open }); });
This happens fairly regularly if the file I'm fetching is big enough. I've hooked my SD card power up to an external voltage regulator so the only thing being powered by the Espruino is itself.
Gordon can you give this a go at your end and see if you can replicate?
Hardware FC is enabled using
'AT+UART_CUR=115200,8,1,0,2\r\n'
file is fetched over HTTP, about 46kb. SD card is at default baud rate. The problem occurs at different stages of the file transfer, but it happens almost every time for me.
Can you think of a board trace I could cut and supply voltage to the ESP8266 myself from another external voltage regulator? Problem with that is the ESP8266 needs a capacitor across VCC and GND otherwise you get these power issues...
Oh I've actually just tried it with the writing to the SD card commented out and I still get the issue.
-
-
Well it seems like it wouldn't be a day of the week if I wasn't requesting some crazy feature for Espruino, but I'm wondering @Gordon if you would consider adding support for WebUSB? Arduino implementation:
https://github.com/webusb/arduino