Search results for:

Yeah, I don't get any of those “Bluetooth:” lines in my system logs at all. I looked in /var/log and in the systemd journal for bluetooth.service, and they're nowhere to be found. Absolutely no feedback on loading firmware. I tried placing the firmware files in a few of the standard locations, but it doesn't seem to improve anything.

Yes, Ubuntu 20.04 is a bit old, but it's still supported, and upgrading in my use case is a major undertaking (and I sometimes need to use “legacy” software which is increasingly difficult to get working on newer distros). I guess I could try booting a newer distro on a spare computer sometime and see what messages or behavior I get on it.

Strange. The forums post shows loading rtl8761bu_fw.bin, but my /lib/firmware/rtl_bt directory does not have that file. The closest filename present is rtl8761b_fw.bin.

I found a Linux driver download on the manufacturer's website (http://www.edimax.com). This ZIP file contains a lib/firmware with a rtl8761bu_fw file (not quite the same naming scheme). Then it has lib/firmware/rtl_bt with a handful of other files in it and a lib/firmware/rtlbt with a rtl8761b_fw. This isn't very consistent with the organization of my system's /lib/firmware directory. I can't really make heads or tails of this.

This is all I get when I plug in the dongle:

[3709401.040967] usb 2-1.7: new full-speed USB device number 85 using ehci-pci
[3709401.158174] usb 2-1.7: New USB device found, idVendor=7392, idProduct=c611, bcdDevice= 2.00
[3709401.158180] usb 2-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[3709401.158182] usb 2-1.7: Product: Edimax Bluetooth Adapter
[3709401.158183] usb 2-1.7: Manufacturer: Realtek
[3709401.158185] usb 2-1.7: SerialNumber: 00E04C239987

No mention of any firmware loading here or in any of my system logs, so I have no idea which firmware file to target. :(

I bought this Bluetooth dongle for a desktop computer running Ubuntu 20.04 LTS, using bluez. It works with my wireless headphones but does not get along with my Bangle.js 2. It regularly takes a dozen attempts or more to connect without giving an error, and even then it might only stay connected anywhere from a few seconds to a minute or two before erroring out and disconnecting, regardless of how close the dongle and watch are to each other. I have a laptop running the same version of Ubuntu, and its built-in Bluetooth works fine with the Bangle. Oddly, I tried this dongle on a Windows 10 system and it seemed to work fine there, too, so maybe the Linux drivers for that chipset are buggy?

To preserve my sanity, I was thinking of trying to buy a different dongle in the hope that I get one that works better. Is there anyone here who successfully works with Bangle BLE on Ubuntu or a similar distro (like Debian or Raspberry Pi OS) who could suggest a specific dongle that seems to work well with it? Or any other suggestions for this problem?

Thanks. It's a relief that the problem wasn't on my end, as I thought I would lose my mind figuring out what was wrong! :-)

I'm trying to do development and have hit a brick wall with a strange problem I can't diagnose. E.showPrompt works fine on my physical Bangle.js, but it fails with an incomprehensible error message when I try to use it in an emulator. Even after clearing all of the persistent in-browser data for the Espruino Web IDE and starting on a clean slate, the following simple example doesn't work:

E.showPrompt('foo', {
  title: 'bar',
  buttons: { "A": true, "B": false }
}).then(function (arg) {
  console.log('test');
});

When I click a button, nothing inside the then() gets executed at all, and instead I get this console message:

Uncaught Error: Unknown argspec 33352

What does that even mean? I grepped the entire project directory and came up with no code matches for “argspec” at all.

It works if I send it to my actual Bangle, but developing it that way right now is quite literally a pain in the neck—my vision isn't very good. I'd rather stick with the emulator most of the time.

That's a neat idea putting it in the App Loader, it'd just require writing a file after we set the time. The only issue is that watch reboots between App Loader runs would knock out the timings, and so if it was automatic it's possible it could end up configuring the PPM difference wrong.

I thought about that. Maybe a sanity check could be performed that makes sure the watch's reported time isn't too far off from actual time, and if it is, the recalculation of the drift could be skipped for that occasion (perhaps with a warning message printed on the console, if desired). Or else have a way to just let the user manually request when the drift should be calculated and the time be adjusted, perhaps.

Thinking about that, I wonder whether something could be added to https://banglejs.com/apps/?id=widadjust to allow it to figure out the drift using GPS.

It would be pretty nice if it had some means of measuring its own drift. Years ago I wrote my own clock drift corrector for a HP 50g graphing calculator, though instead of using GPS it was just based on my periodically entering the correct date and time and manually pressing a button right on the second, at which point it would calculate the corresponding drift. Just a couple of iterations of this quickly made it more accurate than a $50 quartz Timex watch. :)

If there was a way for the app to receive an event when connecting to the App Loader and updating the date/time, it could then compare the new value to the current clock along with the last known date/time of adjustment in order to determine the drift itself.

Okay, so I went back to 2v21 and waited about a day, and so far the clock drift seems more reasonable now, only about 4 seconds over the last day rather than 50+.

But I would like to inform you about a strange behavior: To be honest I did not checked the time before downgrade. But there is no reason for being totally wrong. But after flashing and restarting the clock showed 10:26 pm - but local time was 8:40 pm. After "set time" via web interface it showed the correct time 8:45 pm.

Yeah, when I downgraded to 2v21 I noticed my clock jumped forward a couple of hours, even though the last GPS fix was a couple of days earlier. Can't say I've seen this happen before when changing firmware versions, but this is also the first time I've gone backward a revision rather than forward.

I was just going to post about the same issue with my Bangle.js 2. I am seeing a similar discrepancy, gaining over 50s per 24h. I believe I did start seeing this roughly around the time I upgraded to 2v22, so perhaps I will downgrade and see what happens.

Ah, I see what happened. I thought I had updated my fork, but I was working on a different branch that got old. Now I see that readStorageJSON works. Thanks!

Ah, okay. But I swear that when I try to use Util.readStorageJSON from interface.html it definitely complains that the function doesn't exist, and I have to use readStorage instead. And in the browser console, autocomplete even shows Util.readStorage but not Util.readStorageJSON.

First of all, I totally misunderstood your link to the Storage documentation. I took it as the generic documentation for the Storage module and just now realized it was a special page that contained interface.html-specific information. Oops.

Still, it doesn't seem all that straightforward what functions are available for Util, Puck, etc., that is, I can't find a reference. I can do Util.readStorage, for instance, but apparently not Util.readStorageJSON. Speaking of that, JSON.parse in the browser doesn't seem to like strings from storage files written on the Bangle.js with storage.writeJSON. I had to resort to parsing it with plain old eval instead.

I got the local web server working on Linux, though. That was really easy. Just go into the root of my BangleApps project directory and run python3 -m http.server 8080 --bind 127.0.0.1. Then go to localhost:8080 in my browser, and that was pretty much it. :) I'm posting this here for future reference in case someone finds it helpful.

I think I finally got my desired functionality working using Util.readStorage, though, with a bit of rewriting. There wasn't much code involved in simply printing out the contents from the app, so it's not so bad, I guess.

Never mind, I think I totally botched the syntax. It should be:

      function onInit() {
        Puck.eval("load('timestamplog.app.js')", output => {
          setTimeout(() => {
            Puck.eval("stampLog", output2 => {
              document.getElementById("content").innerHTML = output2;
            });
          }, 3000);
        });
      }

My mind gets along much better with Python than this mess. :D

Thanks for the support. That's pretty much what I figured was going on. I was just hoping there was a more reliable way than using a fixed delay before running the second command, as that seems a bit like a fragile approach since it relies on trying to guess how long app loading time will take.

But technically, I don't really need to load my whole app and its UI. What I'd ideally like is to be able to import a few functions from the app and execute those, perhaps using require() or something. I think I could put some shared functions pertaining to data handling into an appname.lib.js file and export them that way? It seems that I've seen some apps such as Sleeplog do that. It seems that would work more cleanly.

As far as returning vs. printing, I in fact tried both approaches in printHTMLStampLog, because I had no idea what I was doing. It just didn't feel like the docs I read were all that clear exactly how it worked. I understand the Storage.* stuff, but I could not find references to Puck.eval or Puck.write in the search box on the Espruino docs, and I couldn't find an explanation on when to use '\n' and '\x10' and things like that or what the Bluetooth.* functions were. I had seen those in various source code but couldn't find the explanations.

My code involved in this is currently very simple. I could put most of it in interface.html, but it's just that testing that currently involves pushing it up to Github Pages and waiting up to ten minutes just to test the code, whereas I can test code on the Bangle device immediately. I'd have to look into getting a local web server going to work around that, which is another time and effort investment I will have to consider.

Update:
I've changed my interface.html code to this:

      function onInit() {
        Puck.eval("load('timestamplog.app.js')", output => {
          setTimeout(
            Puck.eval("stampLog", output2 => {
              document.getElementById("content").innerHTML = output2;
            }),
            2000);
        });
      }

as a test (stampLog is an object containing simple datatypes), but I still don't get any output. The browser console reports:

BLE> Unable to decode "\r\u001b[Jstamplog: skipping save to storage because no changes made\r", got SyntaxError: Unexpected token '', "
stamplo"... is not valid JSON

“skipping save to storage” is a normal debug message that my app logs to the console, so it's as if it's trying to parse the wrong part of the console (the output of stampLog is way further down than that).

Hi all, I'm working on my first app and am having a really frustrating time getting interface.html working the way I want. The only docs I'm able to find for this are in the BangleApps README, and it just doesn't seem adequate at all.

The problem: I want a “download” button in the app loader that when pressed displays a page with a very simple HTML representation of the data logged in my app. I already have a small function in my app's app.js that returns the desired HTML code as a string, and I just want to call that function and inject it directly into the page as shown in the README example. But for some reason, I can't get it to work at all.

Here is what my interface.html currently looks like:

<html>
  <head>
    <link rel="stylesheet" href="../../css/spectre.min.css">
  </head>
  <body>
    <script src="../../core/lib/interface.js"></script>
    <div id="content">Loading...</div>
    <script>
      function onInit() {
        Puck.eval("load('timestamplog.app.js')", output => {
          Puck.eval("printHTMLStampLog(stampLog)", output2 => {
            document.getElementById("content").innerHTML = output2;
          });
        });
      }
    </script>
  </body>
</html>

The idea is to load my app first (so that I have access to its routines—there's probably a cleaner way to do this, but my focus is on making it work first, then worry about refactoring) and then call the function that runs on the Bangle itself and outputs the HTML I want injected into the page. The app gets loaded, but that's as far as it gets. The second call to Puck.eval just returns nothing, every time. And I can see from the Espruino console that my printHTMLStampLog function does get called and outputs the desired data, but it just doesn't get returned.

What's going on here? After a full day and a half of investigation, I suspect a race condition, because if I fumble around in the browser console and run the second .eval() call by itself after my app is already loaded, it kind of works (except it's somehow not rendering the HTML tags, but we'll deal with that later). I was under the impression that this code would load the app and only call the second part once the first part finishes. Instead, it seems to run the second part too early, and it usually returns nothing, or occasionally, some other nonsense from the Espruino console that has nothing to do with what my app's code is actually writing.

I've looked at a lot of source code for other apps, but it's not getting me anywhere. No one seems to try to use their app's assets directly, and instead they just dump all the code for reading/writing and encoding/decoding data in interface.html. That's not what I want to do because that means needlessly copying and pasting perfectly good code I already wrote into multiple files, and that's a code-maintenance nightmare. I do not wish to take that route. I'd like to leverage the existing on-device app code for this functionality as much as possible.

Can anyone help me get this working properly?

I have similar problems with false positives, and they don't seem completely avoidable by tweaking the settings. I had kind of wondered myself if adding heart rate to the metric could theoretically improve accuracy, but I'm not sure of exactly how that should fit into the algorithm.

I noticed this while developing an app and thought it was odd (unless there's a locale for where this actually somehow makes sense). Especially since, as Gordon said, installing a locale seems to make it behave consistently.

I estimate that I'm typically getting up to around 2 weeks regularly wearing the watch with:

• a clock that updates once a minute
  
• health monitoring set to every 10 minutes
  
• wake-on-twist/motion and so on disabled (despite trying all sorts of settings I never could get them to work well without constant false wake-ups anyway)
  
• some occasional timer/stopwatch/alarm use
  
• not really any GPS use (due to lack of need and because of the relatively severe limitations)
  
  

which seems pretty reasonable. In practice since I use the watch as a daily driver I normally charge a bit more often than that to avoid the battery dying at a bad moment. Since the battery meter tends to hang out around 9–10% for a long time it's hard to be sure what the true max runtime would be without risking that; I consider that level as a sort of “charge as soon as possible” low-battery signal.

I do notice that long use of timers that update in 0.1-second intervals tend to drain the battery particularly rapidly. (At least one app seems to do such updates only when the screen is awake/unlocked and then cuts back to once per second, which seems like a good idea.) But occasional use of once-per-second displays for a few hours here and there doesn't seem to hurt overall runtime too badly.

I'll admit that this threw me off a bit too at first.

It does appear that there is some inconsistency in the standard app UIs as to what Back does, which is unfortunate since it probably makes things more confusing than they could be. For instance, in the Alarms app, going to the menu to create a new alarm or timer, then immediately tapping Back without making changes, immediately creates a new alarm or timer with default settings, which isn't really what I personally would expect to happen. I'd expect the operation to be canceled, or perhaps a prompt asking whether I meant to save the new item. But then in most other places, Back actually does cancel the changes rather than confirming them. It's not really obvious which “rule” is in effect on a particular menu.

In the case of the number-changer screen, perhaps having an OK button on Bangle 2 to set the value would be a bit more intuitive, assuming there is space for it.

Thanks! That seems to work. Darn, I had a back-of-the-mind thought about trying the offline compiler but really didn't expect it to change anything. Looks like I was wrong.

Should we update dane_arwes.js as well? I'm not sure what uses that, but its corresponding dane_arwes.min.js also appears to have a mismatched commit/timestamp. This looks like the only other minified file in modules/ that I can see.

I'm having some confusion regarding the Layout library: I suspect the version of the code in the current emulator and my Bangle.js device does not match what I see in master on GitHub, and I'm not clear on how versioning works. The docs seem to say that the current version of modules are supposed to be automatically loaded from the app loader, but I seem to still have a version of Layout.js that is almost a year old despite having used my fork of the development app loader definitely much more recently than this.

Then I happened to notice in the BangleApps repo that there is a Layout.js and a Layout.min.js file, and the latter is several months older than the former, the former containing the functionality I was looking for but in fact I'm guessing the older minified version is in fact the version that is actually getting deployed. I can confirm this by manually installing the non-minified version into the IDE emulator under a different name (different because apparently if I use “Layout” the built-in version still takes precedence), and I see that the specific behavior of the newer code then works.

Assuming someone simply forgot to update the minified files when making changes, I was going to use EspruinoDocs/bin/minify.js to update the minified modules and PR the update, but I can't get the minifier to work for Layout.js (though I've successfully used it for other files). I get errors I don't really understand; I guess the script doesn't understand the result from the Closure compiler. I've attached the full output log of the minify script.

If anyone could shed some light on how this works or let me know if I'm barking up the wrong tree somewhere that would be great.

That's odd - how exactly were you listing files?

I was seeing the duplication both in the app loader's app list and when browsing the Storage files in the IDE.

I can't be exactly sure when I first noticed it, but it was pretty soon after unboxing. I think the very first thing I did upon plugging it in to charge and powering up was to update the firmware (since the app loader suggested it). I think the old FW was 2v16 or 2v17, can't remember for sure, and I installed 2v18. I think I tried installing apps directly after that.

Anyway, I noticed that the duplicate files did not appear in the ZIP produced by the backup feature, so I tried what you said and made a backup and restored it, erasing storage before the restore. Everything seems intact but with only one “sched” app instead of two, so it seems that solved it.

The codes in the debug log definitely look like terminal escapes, though I'm not sure exactly what formatting they're for. Normally colors and formatting aren't that essential, but perhaps other characters in certain output might be important. If it is just the same output that the left pane in the IDE would display, I wonder if it would make sense to have a button or tab shortcut there for viewing the contents of the debug log using the same VT100 interpretation of escape codes. I'm not sure if the debug log file is an Espruino- or just Bangle-specific implementation, but it seems like a quick-view feature could be a handy debug tool.

The BLE interval makes sense. That would also explain why the response in the console sometimes seemed a little laggy for a moment. Checking the running app is a good point; I should have thought of that but didn't. I've mainly been using Timer Clock as the clock, but I just tried it with the default Anton clock and the first page of Settings and didn't notice any difference in behavior—it still happens the same.

I played with setConnectInterval and do notice that any interval higher than about 100ms seems to consistently reproduce the bad behavior. Lower intervals work okay. So far it seems that this is the only thing that causes the weird behavior.

Yes - this is more laziness in implementation I think. The text is added to the filename in the Storage window so you can see that the files are different (as this can be important), but then when saving the original filename should really be used.
Although... I have to juggle a lot of stuff with Espruino - it is literally just me working full time on this - and it's unlikely I'll get time to put in fixes for all this stuff. If you'd be willing to jump in and make some fixes, that'd be great - as with the app loader you can just fork the IDE and host your own copy with GitHub pages for development if that's easier than having a local server

Understandable. I'm kind of overwhelmed with various ideas myself and it's hard to decide what to do when. :) It looks like the priorities are in the right places, though, as the important underlying functionality seems pretty solid. Most of the things I'm encountering are fairly minor UI/polish type stuff, and that can always be fixed. I may consider taking a stab at some of it at some point.