Search results for:

There is for example https://ifan-display.com/product/1-2-inc­h-round-transflective-tft-lcd/ which is a round 240 by 240 pixel display with relatively small borders. At 1.2" it is a bit small but generally square 176x176 pixel Bangle 2 apps would fit in this with only a few pixels cut off at the corners. So there would be a way to use the "legacy" apps without changes on a round display.
Personally I like square better just for ease of app development.

If you let people write JS they'll try to be clever and it'll no longer be a set of 'do this check that' but something far more complicated

I think this speaks most to me personally :D
I will try to keep it as simple as possible and in json. I guess if we need more complexity we could just run/eval a js file as a step from the json test definition.

I've had a play around porting the first of the test cases to json:

https://gist.github.com/halemmerich/3d0f­1d41d8eebe76eedc8553530e5dd5

I think this should be all the asserts/features I need. I have a rough implementation for those but it is not yet working correctly.

Why did you decide on the json based format for test cases? Wouldn't javascript files be better for editing/linting/syntax highlighting?
Maybe a library that provides asserts and an easy way to setup the emulator for running testcases for a single app? Or the other way round, the test code is a module and apptests.js iterates over the exports which are test functions and handles the environment like now.

You should be able to do all that in a github codespace which is free to use for personal accounts for some time and data limits. But at that point I would probably install a VSCode or similar locally instead.

0.04 seconds per sample matches 25 samples per seconds, so that probably would be the "Sampling rate" setting.
Range might be maximum measurable values, maybe with a tradeoff with regard to precision for the higher values.

I have the TICKR X 2 which should deliver accelerometer data as well, but as of now I did get nothing out of it with neither Bangle nor NRF Connect app. Might be some hidden/proprietary BLE service.

I had done this a while ago: https://github.com/espruino/BangleApps/b­lob/master/apps/android/test.js

Every step in that would probably map nicely to a test object in the json. I think I could refactor that.

Maybe some of the asserts would be useful as a teststep in the apptests? I could try to integrate those.

How does the emulator handle "hardware" like GPS? If it does not I probably need to find a new way to track the state of the "internal" GPS instead of checking the PIN mode like it does currently.

I think you hit a case nobody thought about before. At least I did not. "removable" apps are expected to cleanup all changes they did to global state while they are unloaded. In my opinion that includes the loading of fonts.
Widgets are the one notable exception to this general rule, just because it is not easy to completely get rid of widgets. In your case the app removes the font as it should but the widget still exists and expects it to be there. I suspect the loading of the font only takes place once in the widget and one of the following draws then fails.

1. Clock loaded, widgets loaded, font available globally
   
2. Switch from clock to launcher, widgets still loaded, font removed by clock
   
3. Something calls draw of widget, fails because of missing font.
   
   

There are a few possible solutions:

• Checking for the font in the widgets draw and reloading it if needed
  
• Not unloading fonts at all, probably problematic on Bangle 1 because of memory constraints
  
• Make the loading of fonts more local to app/widget instead of the global graphics object
  
• Attach a counter to a font on load and only really unload it if there is no user left
  
  

There probably are more ways to get this done but some discussion on this will be needed since will affect global behaviour.

One thing that I wasn't 100% clear on was whether OWMweather replaces Weather or if it simply provides it with info necessary to pull weather.

It is neither. OWMWeather pulls weather and writes the same file that Weather uses. You can use it without Weather installed. OWMWeather writes the file and other apps that use weather as written by the Weather app can use it. Weather does use it too and the apps should not conflict.

Interesting, OWMWeather checks if the location data file exists, but not if the location data itself is valid. So the question is, where does the broken mylocation.json come from? At a glance there is no way that could happen in the mylocation app code. To me it seems as if it always either sets both lat and long or nothing. Maybe the web interface needs additional checks before writing the file.

I just installed the android app and owmweather on a factory reset bangle and forcing a refresh in the OWM weather settings creates the expected output:

{"t":"http","url":"https://api.openweath­ermap.org/data/2.5/weather?lat=51.50&lon­=0.12&exclude=hourly,daily&appid=apikeyg­oeshere","id":"72500645030"}

Can you check in the IDE if there are errors when you try to manually refresh in the settings? The "http method not found" error hints to a problem with or in the android app. It should be available on the watch independent of GadgetBridge settings. Maybe your boot code somehow got corrupted, in that case going to "Settings->Utils->Rewrite Settings" could help.

HRM Accelerometer Event Recorder fails with

Uncaught TypeError: Puck.connect is not a function
    at connect (custom.html:253:8)

So maybe a change in one of the app loader core updates?

I don't know anything about scanning or encoding bar codes, but could you maybe get this working by displaying the bar code diagonally on the display to get 2*95 pixels without scaling? It might throw off the scanners when slightly misaligned but could be worth a shot.

Idea: Implement loading tiles along a GPX track into openstmap. So essentially set a scale, move along the track and upload as many tiles as are needed to cover the track in every direction. That would be great for using it as a background for gpstrek or similar apps. I have a implemented a prototype of using openstmap as background for my overview map, but getting good coverage for longer tracks is slow (as in upload time) and needs lots of storage.

The overall shape is done (for now) and brushed over once just to see how it can look and before doing more I will have to wait on ordered M2 screws and a matching tap to hold it together.
I still need to find a solution for getting the button PCB attached and try out if my chosen method of getting a button in there will work at all. I think this will need one more build anyway, so this one is dedicated to experiments :)

Some more changes on aluminium and CAD sides... Actually a bit of matching drawing to reality :)

Not yet, but wrapping it in aluminium foil showed that it could work. Otherwise no way to tell how it will pan out with this dark magic RF stuff before I can actually close the case and screw it down 😉
If there are problems I can always cut some slots into the case and fill them with epoxy to try to get it to work.

Not really, since the uploaded data only contains these 24 hours of data. If you can find another file containing more data for the GPS chip you could use that. If you use Android/Gadgetbridge you could use https://banglejs.com/apps/?id=agpsdata to automatically update the AGPS data in the background.

Thanks :) I cut down the top case a bit to get it closer the final dimensions and started carving out a bottom plate with material left for mounting the board.

Tried the first few cuts. Went better than expected :)

You need to use the Bangle.js variant of GadgetBridge. Have a look at https://www.espruino.com/Gadgetbridge#ht­tp-requests .
You can also have a look at https://github.com/espruino/BangleApps/t­ree/master/apps/owmweather since that does something similar to what you probably want to do.

I wanted to have a go at FreeCAD and thought designing a case for the bangle would be nice to try out modeling something to actually build for the first time :)

Wishlist:

1. USB-C for charging
   
2. Buildable by me
   
3. Not a lot thicker than the original case
   
4. Rugged (primarily better screen protection)
   
5. Screw on back.
   
6. Maybe even waterproof? (Found waterproof USB-C ports on ebay)
   
7. Keep HRM
   
   

TODO:

1. Try making space for a bigger battery (36x25x4 330mAh might fit with about a millimeter more thickness)
   
2. Simplify band mounting (just loops for textile straps maybe)
   
3. Solution for mounting internal components without to much glue
   
4. Find out if I can actually build the thing
   
5. Find out if the HRM can be removed from the original case without being destroyed
   
6. Refine the hardware mockups for better internal space representation
   
   

Has somebody attempted something like this? I am sure this will take some iterations and probably fail in the end but no way of knowing without trying, eh?

I have an old manual proxxon desktop mill that can do about 0.1mm precision and some other tools and want to do this in aluminium.

I'll attach the FreeCAD file but be assured that it probably is not well done as I do not have experience with it or CAD at all.

It sounds like if it is possible at all CPU-wise it will be awfully close. Probably too close for someone (Nordic) to attempt to implement newer bluetooth LE codecs on these chipsets. If it somehow actually works, storage would be the next big problem. 8MB flash is not much to store audio samples.

Oh wow, the confusion was on my end 😑.
My function ignores the first character and so it needs the $ given to it to directly ignore it...

I have tried it with PCAS02, the command to change the update rate and without the $ included in the checksum it changes nothing while including it works.

print(require("pcas").checksum("$GPGLL,5­300.97914,N,00259.98174,E,125926,A")); creates a checksum of 28 which matches your example. Doing the same without $ calculates 6F as checksum.

require("pcas").checksum is as follows:

function checksum(cmd) {
  var cs = 0;
  for (var i = 1; i < cmd.length; i++)
    cs = cs ^ cmd.charCodeAt(i);
  return cmd + "*" + cs.toString(16).toUpperCase().padStart(2­, '0');
}