Please post what you're working on!

Thank you for your answers! I hadn't found the 2018 badge on github, only the 2017 one (which wasn't marked 2017).
I have now downloaded the zips of both projects to my PC, with the aim of making pdfs of the 2018 one. I dont use Eagle, but I'll import them to Altium, which I know how to use.
Do you think I could then upload the pdfs to GitHub?

Mon 2019.10.07

'Do you think I could then upload the pdfs to GitHub?'

Was the intent to include in the Espruino documentation or into a personal account? While most supporting documentation is welcome, not all might be appropriate. What specifically was to be included in the .pdf mentioned? Post a correlated page link that might clue us in to the content intended to be part of the solution. Please explain.

I think @DBovey means to include PDF versions of the schematics and board layout - it makes it much easier to check stuff without having to have Eagle. I've just done that for you now.

Currently I'm working on a sort of bicyle computer using a Pixl.js
It is for a velomobile (DF-XL) and should not only display speed, cadence and mileage, but also watch my battery status.
The velomobile does not have a dynamo and uses a LiPo battery to drive light, indicators, horn and charge equipment via USB. On longer trips it is important to have enough battery capacity (and spares) - especially when riding in the dark.
So I successfully interfaced an INA226 and show voltage, current and roughly calculate the charge percentage.

That sounds great - please could you post up some pictures when it's done? :)

@Gordon sure - will do. Just waiting for the acrylic case I ordered last week - maybe I'll get something finished this week. Will use a RJ45 connector with the socket mounted to the VM (velomobile) so I can take it out for updates or inspection...

I'm also looking at doing a health app of sorts - turns out that quite a lot of people with type 1 diabetes get very sweaty when they're having a hypoglycaemic episode. So I'm looking to create a galvanic skin response reader (with DroidScript android app to do the alerting).

I've got a GSR from Seeedstudio which needs 3.3V to power it - can I do this from one of the digital IOs (which means I can turn it off when not reading to save power?)

Alternatively, am I right in thinking that skin capacitance varies with moisture in the same way that resistance does? IOW can I dispense with the separate GSR altogether and just use capsense?

The other part of this project (unfortunately the end-user I have in mind has deteriorating eyesight) is a simple bit of code (actually running on the Android) which counts the number of consecutive button presses and then performs tasks based on this (so 1 click is open google assistant, 2 clicks is say time, 4 clicks to phone a particular number, 5 clicks is get GPS location and send an email with a link to that location on google maps etc)

Kudos for inventing this extremely cool bit of kit BTW - my first attempts faltered when I realised how awkward it was going to be to put arduino plus bluetooth breakount plus GSR plus battery back in wearable form that was technophobe-friendly!

Has anyone done a 3D design for a star-trek communicator badge yet? :-)

I created a separate conversation - Powering / control power of sensors / peripherals by Espruino pins - to focus on this subject and keep this reference or pointer conversation as concise as possible. I like to put one or few liners here with a link to the full blown, detailed conversation. [Edited... which explains why following two posts may make you feel you missed something...].

Thanks; that makes sense and its handy to know the max current; I've posted on the Seeedstudio board as well so hopefully they will come back with the max current drain. I hadn't thought of using multiple pins; good idea.

And I had no idea that it was important to set the pins to input before powering off, so glad I asked here before continuing!

Just checking, do I do that with something like:

pinMode("D1", "output");
doStuffWithSensor()
pinMode("D1", "input_pulldown");

as per the Digital Dice tutorial? Specifically, should it be input_pulldown or input_pullup (Sorry, I'm sure you were clear in line 4 of your answer to someone with a bit more electronics knowledge than I have!)?

Thanks

Jon

Sat 2019.12.28

'I've got a GSR from Seeedstudio which needs 3.3V to power it - can I do this from one of the digital IOs'

I personally don't like driving external chips/modules using the micro itself, as all those electrons need to flow somewhwere and therefore like to cook (shorten the life expectancy somewhat - but by how much might be unknown) the micro with dissipated heat when driven by those pins. I like to keep things extremely cool, and dissipate heat with buck converters or voltage regulators. As @allObjects has successfully done, it would be possible, but with at least two I/O pins under the following assumptions:

As no datasheet link for the GSR was provided, I took the first five star Google response and ended with this:

https://www.seeedstudio.com/Grove-GSR-sensor-p-1614.html.html

So, if that is the device/module, then at least 20mA will be required (at least by the LM324 as no module datasheet is available)

'Kudos for inventing this extremely cool bit of kit BTW'

Which Espruino board was intended to be used?

'Alternatively, am I right in thinking that skin capacitance varies with moisture in the same way that resistance does?'

Curiosity started me searching, but realized to find the definitive answer will take me too far down this rabbit hole. Short answer - yes but too many factors to consider

See Fig 2a
https://www.sciencedirect.com/science/article/pii/S0006349598740081
https://core.ac.uk/download/pdf/82613398.pdf
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2763825/
"The skin acts like an electrical device such as a capacitor in that it allows more current to flow if a voltage is changing rapidly"

Thanks - and yes, that's the correct GSR device. I've got no shortage on pins I can use for this (as there isn't going to be anything else connected to the espruino). I was planning on using the Puck BTW.

Yes, my vision started to blur a little when investigating skin capacitance too! I guess all I really need is for a reliably measurable change in capacitance as the skin gets sweatier - it doesn't need to be linear, it just needs a cut-off point where it sends an alert. So I think I'll try that first in the interests of reducing the number of components available to stick into my poor patient zero!

Thanks again to both of you! I'll let you know what works.

Sun 2019.12.29

'I was planning on using the Puck BTW'

See comments in the destination link below:

Jon, @user106970 it would make sense to start a unique new thread for future answers. This thread was intended to describe an idea, and we have now inadvertantly hijacked this one. @allObjects started a new thread see #133 link to handle general observations using the same technique you were after. There is a lengthy discussion on pin sourcing for the nRF52 (Puck) chips.

Hi all! I've been working on a project to create a DIY smartwatch, and have started playing with a Puck and an Espruino MDBT42Q breakout - such neat little devices! I'm still working on designing something that will fit in a watch form-factor, but I recently used the MDBT42Q to put together this little self-contained handheld prototype so I can start hacking on it :)

I wrote it up on this Hackaday page, more build logs to come! https://hackaday.io/project/170205-rubble-watch

Thanks, Gordon, for a great platform - Espruino really is a lot of fun.

1 Attachment

Neat! ...and to get rid of the the mechanical / button stuff, you can add a touch panel, such as: https://www.ebay.com/itm/Factory-Outlet-1-4-inch-Resistive-Touch-Panel-Screen-with-Soldering-FPC/292819160320 ... It is a bit larger than you need, but there may be others around... even capacitive one. The resistive though are 'passive' - no noticeable power draw. - on the other hand, the touch panel could be activated the same time as the display comes on.

That looks great! If you didn't go for a touchscreen are some nice thin switches like are used on the Pico - you could maybe get 2 down each side of the LCD.

It's not 'official', but I'm still doing http://forum.espruino.com/conversations/332911 - so please could you drop me an email and I'll give you a coupon code for the Espruino shop? It might help with the next version ;)

Thanks allObjects! And thanks Gordon, that's very kind, I'll email you.

I have a Fitbit with a touchscreen which always makes me feel like I have fat fingers, so I think I'm gonna stick with physical switches :) I'll look into some mini ones like the Pico - seems like Digikey has a good selection. Still trying to decide if I can pull off a usable watch with off-the-shelf breakouts etc., or if I'm finally gonna have to bite the bullet and learn how to design a PCB....

Issue with touch screens of fit-bands and a-like is that they do not have many areas... usually just one, and bangle.js has two: left and right.

Right now I'm messing around with emulating the NTAG215 NFC specification, it turned out to actually be fairly straightforward to get the basic stuff working.

Hello all!
I wanted to add a very basic use case for the Puck.js (v2): As an addition to the tutorial on BLE HID media control by @Gordon I added volume control by physical rotation of the device (since v2 sports additional sensors). Here is a short demo:
(https://www.youtube.com/watch?v=3Md_5bTZ-r0
)
The (rudimentary) code can be found here: https://github.com/rbtrrnss/Puck.js-volume-control

Thanks for the awesome hardware!

Wow, really nice! You're actually using the magnetometer rather than accelerometer/gyro?

Yes, the gyro is what I intitally wanted to use. But it gives me random high value readings (even with no motion at all), which seem odd to me, so I switched to the magnometer.

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)?

That's great! Are you using an MDBT42 with external aerial? If not, you could maybe get away with just a Pixl.js (which still has the same bluetooth).

will BTLE scanning always have priority (like interrupt handling)?

Yes, it should be fine - as long as you're not using Bluetooth to talk to the Pixl?

One thing to watch out for is to get the setScan handler as fast as possible though. While BT scanning is in an IRQ, if you don't handle the data from it fast enough then potentially you could lose some

Thanks, @Gordon.
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?
  
  

The 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?

Are you willing to share your code? Maybe you could put it in a new post and I might be able to take a look at the setScan handler and see if I can offer any pointers?

If you're not already, using the 'filter' as a second argument to it should help to reduce overhead by allowing espruino itself to filter out un-needed packets.

Interrupted during event processing

This happens is Ctrl-C is sent (which the IDE does automatically if it doesn't get a response) when the device is busy processing events - so yes, that's probably related.

Either some JS code is taking a very long time to process, or there's so much Bluetooth traffic it's spending all its time handling it.