> For example If I use a 100A 50mV shunt how can I tell the software that a 50mV drop = 100A? I
Currently, you can’t (AFAIK). But there have been already more requests in this direction, so perhaps it will get implemented someday.

Just some days ago, I made a similar, but more generic suggestion for external shunts, sensors, etc.:

As it seems impossible to consider all possible external sensors and devices, I suggest a flexible concept of some (say, 10 or 16) user-definable and -nameable “profiles” where free math conversion formulas (and/or even filenames of user-stored lookup tables) can be entered and saved. The already existing temperature conversions could then be made a (pre-defined) part of this concept. (see here)

Anyway, please be aware that even if some kind of such feature would be implemented, it would only work at app level, so it would influence the app display, but not the logged data. (Otherwise, it would have to be implemented at firmware level, but the small firmware memory would surely not allow that amount of extra functionality.) So logging stores always raw data (for example, temperature always in Kelvin); you need to apply your own conversion/postprocessing if necessary.

Would it be possible to write free math functions to log header directly from app? Firmware would only need to allow writing through bluetooth (it now does reading).. So we wont get stuff calculated for every log line, but have at least right function saved to use in post processing..

My wishlist for log header:

a) Human readable start (and stop, if done from app) time+date (+function to convert timestamps for human consumption with right time zone etc)

b) Free math functions for as many “virtual-channels” that we could came up with. (No actual firmware load, just the functions+units that are set up in app as setting up and testing the whole experiment, so data gets same treatment at field and at office). And of course, free math need to be implemented in app :D .. And if free math functions are saved to log file, it should be easy(?) to add free math channels with right units in mooshigraph-webtool etc..

c) Not actually for header, but maybe additional column for crash recovery information etc.. Is there something like this already? I have seen some undocumented numbers appearing in logs, should we know what those mean? And should there be more? Not crashes ;) but some status messages when everything is not right.. Like low battery warning, so when the meter crashes, there would be some traces left behind..

d) Free text field for naming your experiment. And when things go professional, site/operator/devices/etc, but it would be probably best to keep everything in one text field, as if there would be 20 different boxes, some mentally challenged would want to fill all of those and forget to measure anything :D

Oh.. How did i get that far from the subject.. I’m not a fan of “forced” pick-list type thing, free math is the way to go. I don’t want to see a list of 700 addons that i don’t have, Manfred has a point in user generated stuff (so we all would have lists of our own, but i would not limit it to just 10 or 16). I have already used random resistors as shunts with even more random current transformers etc.. Normal people use shunts and current transformers independently and that is just a beginning in my experiments ;) Couple examples would be ok, if user is able to modify/delete something that is not useful..

Downloading .csv:s over bluetooth is already implemented, so logging directly in app seems obsolete to me..

But. Its not possible (at now?) to log buffer mode, which gathers raw data at samplerate set at meter screen without actual sampling (that other setting at bottom of meter screen).

Mooshimeter can do 4000Hz samplerate (8kHz seems to be unstable and James might hide that from options at any time.. I may have read that between the lines, so im not sure). There is no trigger mechanism in hardware, so our only option in buffer mode is to randomly shoot and hope to hit something useful.. Buffer mode might be more useful, if we would be able to stop automatic refreshing. Now you have to decide in ~half a second if you want that data saved and only saving option is to do a screenshot of it. (or is it? –> )

Hmm.. Had to test, i had never realized that stopping autoscroll in buffer mode actually does something interesting.. It seems to keep timeline intact and just add bursts of data to it when its available.. Still stopping whole data gathering would be nice, as finding and analyzing your data for an hour while constantly getting more would probably break something..

@admin :
Also that buffer mode timeline stuff is broken, only one channel is scrollable and other one stays still.. May be related to normal graph mode problem, where we cant scale/move other channel?

> Another GREAT feature would be to allow Logging from within the App.

This – and a lot of other user-defined functions – will be possible without having to be implemented in the app itself as soon as Broadcast Intents are properly working with both channels.

See https://www.docdroid.net/3ZLahNf/mooshimeter-app-can-perform-other-tasks2.docx.html for some examples, including logging.

At leat in the beta app, it shoud be working already if only one channel is relevant, but this would be a provisional solution. Probably the communication parameters need to be changed in future to address the 2nd channel problem. (I read it somewhere, but I can’t find it again.)