Search results for:

Okay, the little arrow I overlooked so far. That's really useful. I can certainly add something there in the future.

Thanks for double checking! I will try the same with my scope. And I agree, let's not chase ghosts.

No, that was just a guess. What I see is that the connection breaks down. From the source code it is clear, that the BLE stack goes into sleep mode. Then later it wakes up again. The mentioned function looked like a candidate. But if you say that the NRF.sleep() is not supposed to be called with an active connection that's fine with me. I was just not expecting that and thus thought initially it might not work. Personally I think a hint in the documentation might be helpful there.

The RC oscillator sounds like a possible reason. Since it is short and only occurs every 7 seconds or so that's no issue for me.

The remaining issue is the behavior before calling "NRF.setAdvertising(...)" for the first time. There the power really goes up for 3.5 s and ramps down for 3.5 s. In think there is some serious current flowing during that time (if one accepts 80 uA as serious :-) - well, if the expected current is 20 uA, then 80 uA is serious). This goes away after calling NRF.setAdvertising(...) for the first time. Since I now have a workaround there is no big problem for me, but I think it is something to be looked into - if anyone else can reproduce it...

@Gordon, actually I did that first, but mine isn't accurate enough, either :-(

Hi @Gordon,

So I did some more measurements with the suggested capacitor. I used a 1 uF capacitor which should be plenty for smoothing out things a bit (actually the Puck can run for a couple of seconds off the capacitor before losing the connection to the web UI).

The measurement for the connected state is basically the same (~270 uA). The measurement for the advertising / disconnected state is smoothed out but still looks pretty weird: It stays at 12 uA for a bit, then ramps up to 80 uA within 3.5 s and then goes back to 12 uA again witinh 3.5 s. So we basically have a 7 second loop where something is happening. Without the capacitor it is similar, just a bit more fluctuating. Note that this happens with an empty Puck (reset() + save()) as well as with one which is watching a pin. Basically the same behavior. So something is going on every 7 seconds which draws quite a bit of power when advertising.

I also tried to switch off the bluetooth sender/receiver using NRF.sleep(). That does something: I immediately lose the connection from the web UI. But apparently it still advertises bluetooth. It still has this power cycle described above. And I can connect to it later using the web UI. I checked if the NRF.sleep() somehow causes a reset by lighting the LED on reset for a second. So that does not happen. So apparently either the bluetooth is not switched off completely. Or it is switched on again.

This is with the latest firmware.

Any ideas?

UPDATE: It seems the disconnection from the IDE triggers a reset of the bluetooth stack (in jswrap_bluetooth.c, bleUpdateServices). So that explains why the NRF.sleep() does not switch off the bluetooth stack. It only works when there is no bluetooth connection. I called it from a timer and then the current goes down to ~12 uA. But still once in 7 s it goes up to 24 uA. This is independent from a setWatch on the button.

UPDATE2: When setting the advertisement interval to 750 ms, then the power fluctuation is much faster. When setting the advertisement interval to 2 s, then it fluctuates between 12 uA and 30 uA every 2 seconds. That's kind of what @Gordon also measures. So my conclusion is that the fluctuation is somehow connected to the Bluetooth advertising interval. Maybe there is something wrong with the initialization of the Bluetooth stacked which is fixed when calling NRF.setAdvertising(...)? Interestingly enough with that setting even in the NRF.sleep() state the power consumption seems to be still fluctuating between 12 uA and 24 uA every 7 seconds.

I will try the idea with the capacitor, great suggestion! I will post the new results when I have done that. But again this could also be related to measuring error.

@allObjects: I looked into the Online Profiler a while ago, but it does not help that much. It does not allow to specify watches on pins and timers and so on. Maybe they do not have much influence on the power consumption. For other microcontrollers, they do. But that's what I am trying to find out.

I did some measurements of my own using a similar method. Basically I 3D printed a CR 2032 replacement and put a cable on top and below the replacement.
The numbers I measured are a bit higher than what you mention, about 270 uA when connected, 8 uA when not advertising and have the watch set. When advertising the current fluctuates so strongly that it's difficult to judge. But it seems in the same ballbark of the 20uA.
So all in all it's all the numbers are in the same ballpark and the differences in measurements could be measurement errors on my side. So battery lifetime seems to be excellent and I can now measure how much current different applications would draw.

Thanks, sounds perfect! I will try it out!

Hi @Gordon, thanks for the info. So I guess trying the advertisement way is something I will do next. And I will check the tin foil approach, that might be easiest, indeed.

One thing I don't understand is how to use the Web Bluetooth with multiple Pucks. I did not find a way to connect to more than one from the same web page. Could you elaborate on that a bit?

Thanks!

Hi, I today tried changing the transmit power using the above mentioned function. No matter what value I set (from the list of mentioned values) it did not seem to have any influence. I checked with an IPhone and the NrfConnect application. The RSSI was always the same although I change from -40 to 4. I checked the source code and the function is wired up to some Nordic library function, it seems. So this seems to be really weird. Anyone else saw that effect?

@allObjects, 7 connections to slaves would be perfect. That would mean the game could have 8 players (if I had 8 Pucks :-) ).

I am interesting in the current when advertising over BLE and listening on the button pin. That would be when the game is not used which could be for months. Then when someone wants to play the game they press the buttons on the Pucks which would be needed for the players (one for each player). They would wakeup, would connect to each other and then the game for be used for a while. Then when the game was finished they would go to sleep again, until next time someone wants to play. So the current in the idle situation is important.

Hi @allObjects, thanks for your comments, appreciated! But actually I knew about the sleeping part already. But in other microcontrollers (e.g. Attiny 45) actually waiting for an interrupt to happen on a certain pin will pull some extra current. So basically if you are in deep sleep and you do not wait for anything, it will only pull 0.1 uA. If you are waiting for a pin interrupt or wait for a timer, then you are at about 2 uA. So the question is if the 20 uA mentioned are still the case if a timer is set and a watch on a pin is set.

About the connecting, disconnecting: I see that connecting to another Puck takes about 2 seconds as in the "controlling another puck" example. But when you stay connected it is very fast. But for a game like shown in the video, building up the connecting for every interaction would be too slow. So the Puck needs to be able to maintain multiple connections, I guess. Or some different method is used. For example I could imagine that the advertisement data is used and changed when something happens. That would not require a connection thus could maybe be fast. Not sure if it would work, just an idea...

Hi @Gordon,

one of the things I liked in the Kickstarter video (or was it some other Puck video?) was the multi-puck game where 4 Pucks were shown and you had to press on the one which was illuminated. I plan to do something similar, but the question is how was that done? So one master connecting to all the peripheral pucks? I am not 100% sure about how many connections the Puck can handle. Would that work? Or any other advise how it was done?

Another question also interesting with the game: you write the power usage if BLE is advertising but the Puck is idle otherwise is 20 uA. So I would like the Pucks to be idle all the time until the button is pressed in which case it would start looking for other Pucks. If you do a setWatch is that still counting as idle? Or does it involve more power consumption. Measuring is a little bit tricky without soldering something to the Puck which I don't wanna do at this point. So maybe you know...

Thanks!

Absolutely, congratulations also to @aplikatika! Sorry for forgetting you in the excitement.

I just had a session with @Kolban. We were able to get Espruino running on one of my ESP01 boards. I could run all kinds of JS including connecting to the network and listing the access points in my vicinity. Wow. Congratulations to @Gordon for making the really cool Espruino and @Kolban for porting it to the ESP01. This is really a cool addition to the Espruino family. Certainly not as easy to use and setup as the Pico but still very useful!

Even with the best libraries - not even Arduino - can hold the candle to the setup of Espruino

FWIW: I agree.

Cool. It would be interesting to know the relative speed of the C implementation and the JS implementation. I guess for most things it does not matter that much, but it would be good to know.

That looks pretty much like what I was seeing. Only it took ~300 polls for it to happen, most of the time. Sometimes it also happened after a few tries.

Interesting in that context: I was now able to use the ESP 8266 without the Espruino. Turned out that my old trusted Bub II FTDI board does not work with it. It works with pretty much everything else, but according to someone else a 1 MOhm resistor is keeping the ESP to work with it. I now use a Teensy as a passthrough serial adapter. With that I was able to use the AT commands and also update the firmware.

I then installed NodeMCU on it and did the same test. Same result :-(. After about 300 requests it got stuck...

Well, in any case, the input buffer is in fact modified so jsiConsolePrintf works fine.

And looking at the source code of the AES code, I believe modifying the input buffer is not necessary, and as such probably unintended. I would bet on that. But technically it is not a bug unless there is a promise that it does not modify the input buffer.

And I don't have the slightest idea why AES_128_CBC_encrypt_Buffer is doing that.....

Because in line 512 XorWithIv modifies it? Maybe that should be

    BlockCopy(output, input);
    XorWithIv(output);

Are you sure that above is the correct source code? The one you actually tested? It seems to me that the int and hex output are the same values. So let's concentrate on the hex one, only. In that case it seems as if what you are outputting is

jsConsolePrintf("%d", in[i] + i);

Does that ring a bell? Are you somewhere modifying the in array? Otherwise it would be an extremely odd bug of jsiConsolePrintf. One which adds an increasing number for each call. And which resets itself which you switch from %d to %x... Unlikely...

To my knowledge it will only allow a string. Consider using jsiConsolePrintf which is pretty much like the usual printf. Does that help?

And @Gordon: Congratulations for adding Java to Espruino. I missed that. Is it running in parallel to JavaScript or alternatively? :-).

@Gordon, I have tested it with 3 different modules, always the same. I stripped down to pretty much the example code, still had that. But I heard the same also from others. It is sufficient to reset the ESP to "heal" the problem, so I am pretty sure it is not Espruino.

+1 for a way to update the firmware!