Topic | App release 26, FW 1466836533

Home Forums Mooshimeter Support App release 26, FW 1466836533

Viewing 9 reply threads
  • Author
    Posts
    • #10399 Reply
      Duane
      Guest

      James, Looks like you have been busy. On 6/26/2016 I downloaded app release 26 from https://github.com/mooshim/Mooshimeter-AndroidApp/releases. Note Playstore latest was at release 25.

      Appears most of the issues with graphing in my previous posts have been resolved. Great!

      One issue I saw before, but more apparent now that other issues are resolved. Buffer mode of 120VAC wall socket, 4000Hz/256smpl, android 4.4. Happens every several seconds.
      buffer mode

      I see lots of good improvements in the logging. However, I still see:
      In between logging sessions I still find it most reliable to reset meter. Otherwise sometimes it still doesn’t log. The bigger issue is I see no way of knowing at any given point whether or not the meter is actually logging. I used to think the LED blinks were the definitive answer, but I am not sure now.

      Sometimes the log file will have a header with a few rows of measured data that is all wrong preceding the header and good data.

      — Duane

    • #10410 Reply
      Anonymous
      Guest

      2 meters, 2 cell phones, each logging different sources all night. This morning the logs looked great. Only one file each with one header, beginning and ending timetamps are correct, and measured values are stable. Kind of exciting; this is looking really good. By the way, in case other folks are curious, I have no problems with 2 meters/2phones both operating independently just a few inches apart. So, I guess BLE does have some redeeming qualities :)

      It wouldn’t be realistic to have all this good news without a however. So here it is. However, on one of the phones (both phones are android 4.4), when I made the app display active this morning after logging all night, the display became active in the correct configuration for several seconds, then reinitialized and came back up in the default configuration. The log files correlate to this. A separate file was created (separate from the file with all the good accolades above), with two headers, one correct config, followed by default config. Just in case it matters, when I log, I press the back arrow on top left of the display to make the app display inactive. To make the display active again, I select the meter from the list of meters (usually only one) in the app.
      —- Duane

    • #10427 Reply
      admin
      Keymaster

      Duane –

      Thanks again for the precise feedback! I made a note of the “Android app reverts meter settings after connection” issue. I left two meters logging all weekend, one at a 10 second interval and one at a 1 second interval. I think I saw the same thing happen when I reconnected to the 1-second interval meter.

      Regarding the “chirp” of noise in buffer mode: I had not seen that issue. I just reproduced your setup and I can confirm that I see it now too. Every 6 or 7 screen refreshes there’s a chirp of noise. My suspicion is that this is on the app side, because the AC readings I took over the weekend look clean.

      Thank you for finding this, I’ve made a note and will have a diagnosis soon!
      ~James

    • #10430 Reply
      Anonymous
      Guest

      James,
      In the first post above, I wrote “Sometimes the log file will have a header with a few rows of measured data that is all wrong preceding the header and good data.”

      Now I see the same thing in your original logfile from this weekend logging. Is that from a BLE disconnect and auto-reconnect?

      By the way, nice weekend plot example.
      —- Duane

    • #10440 Reply
      admin
      Keymaster

      Hi Duane,

      I found the “chirp of noise in buffer mode” issue. A buffer was getting reused too early… it will be fixed in the next FW release. Thanks again.

      I still have not wrapped my head around the “several extra rows at beginning of logfile” issue.

      ~james

    • #10443 Reply
      Anonymous
      Guest

      James, Your dedication and support for your product is amazing.
      — Duane

    • #10455 Reply
      Anonymous
      Inactive

      Hi James,
      This App/FW update is working pretty well for me. In particular I noticed that I did not need to switch bluetooth off/on after the firmware update — have you found a way to flush the Android cache of Bluetooth devices?

      I do encounter occasional connection failures on starting the app. The error is always either
      “Initialization failed: Status: -1”
      or
      “Connection failed. Satus: 133”
      Pressing the scan button is usually enough to trigger a successful auto-connection. I noticed that after an error it resets to the default readout parameters (Current DC + Voltage DC).

      I also noticed similar buffer-mode glitches to those described by Duane above.

      One last comment for now: the independent graphing grids for the two channels makes the plots rather hard to read. I appreciate that the logic involved in this is tricky, but it would be nice if both traces could share the same grid-lines. For example, if trace-1 varies over 1.9 to 3.1V, you might choose a grid-spacing of 0.5V and an axis range of 1.5 to 3.5V. And if trace-2 varies over 0.1 to 5.6A, you might choose a grid-spacing of 1A and an axis range of 0.0 to 6.0A. That gives 5 grid-lines on trace-1 and 7 lines on trace-2. In this case it would be nicer if the range of plot-1 were extended to 1.0 to 4.0V, meaning both traces could use the same set of 7 grid-lines.

      But aside from these minor issues, I’m really enjoying using my Mooshimeter. I don’t know why other multimeter manufacturers aren’t falling over themselves to copy the concept. Keep up the good work!

      Tim
      (Nexus 5 with Android 6.0.1)

    • #10458 Reply
      admin
      Keymaster

      Great feedback, thanks Tim!

      Sharing grid lines on the graph actually wouldn’t be too tricky, because I already implemented that in the iOS app. Good catch, thanks, it’s something I always intended but forgot about.

      Regarding status 133 and -1 when trying to connect: -1 is a timeout, 133 is GATT_ERROR… unfortunately the only way past them is to try again. Under the hood the Android app is already doing a few retries because those errors get returned much more often than is visible to the user. So I’m afraid there’s not much I can do about those right now.

      Regarding the chirp of noise in the buffer: I just finished pushing the fixed firmware with the iOS beta, will be bundling it with the Android release now. The new version code on the FW will be 1467155160.

      Duane: Thanks :) I feel like some day in the coming months everything will stabilize and I can take a break, maybe design something new. But until then gotta keep squashing bugs!

    • #10477 Reply
      Anonymous
      Guest

      James, You can never take a break. What will happen when Android v10 will be out? Will the mooshimeter be usable?

      You will be able to rest only when mooshimeter is fully supported by sigrok. That will guaranty the long term usefulness of the meter.

      Thanks again for all your hard work!

    • #10527 Reply
      admin
      Keymaster

      Truth. Android is getting more consistent… 5.0 is better than 4.4, 6.0 is better still. The arc of history is long but it points towards improved Android BLE support.

Viewing 9 reply threads
Reply To: App release 26, FW 1466836533
Your information:




This site is protected by reCaptcha and the Google Privacy Policy and Terms of Service apply.