Search results for:

ah good point. got my numbers wrong! doh. 🤦‍♂️

also, I think the UARX and UATX pins can be configured as analog IO so you could use buttons with resistors against those for a simple solution also?

Basically there is a mix of C++ and Javascript that makes up the working environment. The build tools will build a combined firmware "hex file" that combines the bootloader, the firmware and the basic bangle bootstrap apps.
Obviously it all depends on what you're interesting on doing or working on for which bits of the environment you actually need to build.

Yes, that is the firmware you need. The building guide is https://github.com/espruino/Espruino/blob/master/README_Building.md building in your case with a BOARDNAME of BANGLEJS2, that will build the bootloader and espruino interpreter to install (along with the bare minimum bootstrap apps)
Once those are up and running then the functionality and apps are provided from: https://github.com/espruino/BangleApps again there is a readme there with a lot of information on how you can build your own and/or create your own forked "app store" to use.

Latest full build working like a charm. Got a board.js file setup and running Espruino! 👍
(haven't had time to check everything works, but I can talk to the battery monitor and the screen)
Espruino rocks!

How long is the cabling? might be worth adding some external pullup resistors in case the internal nrf ones are too strong.

Hi this is a forum for discussing the Espruino javascript environment, you probably want to look into the Espressif site/support for this: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/twai.html

Great, progress. Thanks. Right, next to get some programs up and running.

brilliant @fanoush thanks, that's a great starting point... still no picture but getting there.

I've just started playing with one of these - and this works well, I'm running over the Bluetooth serial console, and the upload as uf2 is nice and fast.
I've connected it with a Seeed Round display before I dig too far, I wondered if anyone else had used this combo already.
I got (slightly) excited when I saw that the screen controller GC9A01 was in the codebase, but (I think) it's only compiled into the jswrap_bangle.c file and not available to a base Espruino build as a js module, and I couldn't see a compatible module already to use.
I did briefly try a tweaked bangle build, but unsurprisingly, that just created a screen of random garbage and appeared to freeze on boot so decided to leave that for now, although I think that might be just because I'm still using the AdaFruit uf2 bootloader and I should switch to the full bangle build.

So, before I go any further, just wanted to ask/see if anyone had done this combination already - I assume I just need to create a new js module probably based on https://www.espruino.com/modules/ST7789.js

I was planning on printing a custom case and hooking up two buttons to the NFC pins so I think this would work pretty well with a bangle build.

Since I wanted to make sure it all worked I popped on a (cheaper, sacrificial) BG95 to test... and it only flipping well works, gets GPS satellites and connects to a mobile network! I am astounded and chuffed. This was the most complex thing I've ever designed and worked on.
If anyone wants more (longwinded rambling) details I've got another rambling write up - blog link.
I haven't got around to it yet, but I'll also upload the pcb layout and design files, probably this weekend.

Cheers Gordon, that was step zero of the project (also to document) - build a hotplate. 😁 The software could do with improving (I could never get the PID control working, so I just timed and hardcoded it!)
Oh ok, perhaps I'll stick with the TP4096, I saw comments that it wasn't a good choice when you have an attached load so I was considering the TI BQ21040 instead which also has a wider range.

you won't need pullup/down resistors you can control that internally on the gpio ports. You'd want to connect the buttons to gnd with an internal pullup.

Pity you can't caption or annotate pictures.
The board is similar to the rak5010, but includes a voltage convertor so has native 3.3v IO and exposed I2C, also connects more of the BG96 IO for both AT and GPS serial streams and uses a MAX17048 'fuel gauge' for useful/reliable battery state. I haven't included sensors since I think it's easier/better to hook those up with I2C (e.g. I found the on board temp sensor of the 5010 was pointless since it heated up with the board)
Exposed both the NRF and BG96 to USB, added a JTAG socket.

I've had to make two manual patches on the board, but have also just blown the BG96 🤦‍♂️
Will switch to a USBC connector, and currently using a TP4056 for the charger, but I'm considering switching to something more advanced since I definitely need to do another build and board update.
Also using a Holyiot-18010 NRF module, but wondering if there's a better choice for this.
(and lesson learned SOD523 diodes are the work of the devil, going to swap those on the next design.)

I really need to get around to writing this up properly, but thought I'd post some pics to encourage me to start documenting progress.
I had been using a rak5010 for a project although I ended up making lots of hacks and improvements to the board, so thought I'd try to design and build my own....
This is the most complex build I've ever done and it's not going smoothly, but I'm still making progress and getting there.
When (if?) its finished and working I will have all the designs uploaded.
Initially I'm getting a custom app working on it, but I should be able to get an espruino build going too since it's similar to the rak5010.
Getting there, pics attached of the first board (green) that had a design flaw, second board (purple) first fully built board, finally running (but due to power fault first bg96 blown and removed 😠)

oh wow I love the idea of the extra button hack one thing that I really miss from the bangle1 on the 2 is extra tactile buttons. I think you can make much easier to navigate user interfaces that way.

Issues: https://github.com/espruino/Espruino/issues
Possibly this one? https://github.com/espruino/Espruino/issues/2435

Hi, previous thread re S3 support:
https://forum.espruino.com/conversations/372053/ and the repo with the build of v2.16: https://github.com/rgomezwap/EspruinoS3

This is amazing! I've got a little project to refurbish some 'heritage' window fittings at the moment - modelling them on my 3d printer - and this looks like the perfect service to get them fabricated properly 👍 (also a little bit jealous of your mill) 😀

yeah, excellent info, basically "no" :)
but also how do these 'alliances' create such hard to understand or follow specifications? is it on purpose to prevent people implementing them, or am I just not on the right wavelength?
I recall wading through the mheg specifications ages ago trying to add support for part of it and it was similar pages and pages of disjointed statements.

I used running footpods from the days before 😱 wrist based gps and have spent way too long thinking about the subject and looking into it on various projects.
(including one of my more recent projects building a GPS tracker where I spent some time looking at the distance calculation from GPS data)
Basically you're right with your ideas about smoothing and responsiveness of stride monitors. There are actually cheaper footpods than the stryd that can be used too (from both garmin and suunto) although I think those are ANT+ only which isn't (natively) supported by the bangle firmware.
If you look at the footpod profiles for ant (and bluetooth) it's pretty simple protocol and is just basically calculating and giving a "stride" count/length based on a fixed calibration. (the stryd has power and other metrics in addition) Earlier models of garmins etc used to have a calibration step you needed to define this where you'd run for a fixed distance and it would set a ratio. Although I believe there were some auto-calibration options in later garmin versions where it tried to calculate this value in reverse off the GPS data (I assume it detected a straight line for a period with quality GPS)
Interestingly the earlier Garmin e.g. 310XT seemed to actually use that stride data to improve and smooth the GPS tracks it recorded (fellrunr did some tests showing this, also has good commentary and reviews about themin general - https://fellrnr.com/wiki/Footpod), but that seemed to be left to history as the watches improved and I expect they found other tricks to achieve that.

The other problem with the GPS data was the "wobble" this has improved considerably in recent years with the different multi-band chipsets and the overall improvements in accuracy and consistency but can still be an issue where if you're measuring "second to second" whilst you'll get a smooth trace the actual points are actually slightly off by a small amount each second, so for the overall trace it's fine and smooth, but if you actually take the instant data and use that to calculate pace then it jumps back and forth due to the small distances on the calculations.
You can smooth the GPS data to get a more accurate speed data but you need to take into account, as you say, whether the path is straight or "bendy" but it's basic trigonometry, the downside then is the lag you introduce into the returned data.
(also where I was calculating distance taking into altitude and curvature of the earth I did worry about the extra calculations I was doing on battery life!)

The lag is something you definitely notice on a Garmin (without footpod) so I agree re footpods giving more accurate speed data, I've always used them for instant pace data or sprint data, so yes I reckon you definitely could get a puck to calculate this.
I'll try to see if I can find some of my old code to calculate this (albeit that was for TI340 based chip) it was just detecting the "hit" of the foot from the G sensor, then getting the max of the acceleration between that and the next "hit" and from that estimating the speed, would definitely be a fun puck project.

However it's quite a lot of work

Yeah well, everyone needs a hobby. :D
Definitely some interesting phone modules, albeit most of the breakout all-in-ones seem to be 2G only. So a custom board is probably the way to go, might have a play.

not much better than a Nokia candybar phone

Yeah I still use an ancient Sony dumbphone when I don't need connectivity, but I like the flexibility of the js runtime you've created with espruino which you'd still be missing on a candybar.
Just thinking the hybrid of a flexible "bangle" style ecosystem on a handheld but with the added built in connectivity and obviously phone functionality might be fun.

This is just pondering/thinking out loud....
I've been going through a phase of really disliking pretty much any current/modern smartphone, and I had been looking and pondering alternatives and saw devices such as:
https://www.thelightphone.com/ although as far as I can see that's still just an android phone under the skin, but stripped down, so still limited hacking ability.
but seeing components like this: https://www.dfrobot.com/product-2323.html made me wonder, could a reasonable hackable espruino driven phone be constructed with a small number of basic off the shelf components?
(I had pondered the rak5010 for the guts since I'm very familiar with it, and it's got an impressive set of features, but looks like the BG9x only has VoLTE)

Loving (and watching) this project, I actually have, and use one of the LitterRobots which is actually pretty good to use day-to-day, although I have been meaning to modify/work with the onboard control board at some point which could be better.
having said that - I have a higher priority project to work on first which is to figure out the protocol for the SurePet cat flaps, since their software/setup is really lacking (aka dumb as a box of bricks).
(even with "internet" control it needs DST manually updating, and loses all it's timing settings when you change the batteries🤦‍♂️)

Someone correct me if I'm wrong... but I believe what's happening here is that during the bootloader the bluetooth hardware is initialised before espruino starts to run, the fact that your other device had stored the bluetooth mac address means that it detects, recognises and shows up the device during this process. Then once it boots the bluetooth is disabled.
This is how you can flash and update the device when it powers up/doesn't boot. I expect the bootloader code could be changed to not activate bluetooth at all, but would make it less user friendly if it needed to be bootable to be able to flash.
I guess/expect that code could be added to set a permanent flag that the bootloader could read during initialisation (although I've not looked at the bootloader code), but again that would open the possibility of ending up with a non-flashable device.