Topic | DC External Shunt mV Ratings & Calibration

Home Forums Mooshimeter Support DC External Shunt mV Ratings & Calibration

  • This topic is empty.
Viewing 6 reply threads
  • Author
    • #15022 Reply


      Everything about this meter seems great, except for documentation on using external shunts. I have piles of 50mV, 75mV and 100mV shunts but nowhere in the documentation do I see how to define in the software what the mV rating of the shunt is or what the amperage of the shunt is. If I can’t tell the software what a 50mV drop means in terms of current how can it work correctly? This would be a GOLD MINE product for the solar industry but we need accurate current display, graphing and instructions on which shunt to choose.

      For example If I use a 100A 50mV shunt how can I tell the software that a 50mV drop = 100A? I need this device to graph and label/identify the correct amperage. I plan to use this for solar data logging & 20 hour battery capacity testing, but the documentation on proper use of external shunts seems to not exist? What am I missing?

      Can you please provide us more information on the use of external shunts. 10A DC is entirely useless to me and I need to be able to range upwards of 500A for certain measurements via a shunt.. It seems that a “pick list” of shunt ratings would suffice.

      eg: In the software – “Pick Your Shunt”
      50mV – 100A
      50mV – 200A
      75mV – 50A
      75mV – 100A
      75mV – 200A

      etc. etc..

      I am about to buy one from Circuit specialists so this info is critical..



    • #15024 Reply

      > 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.

    • #15029 Reply

      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..

    • #15037 Reply

      I fully agree that there should be some usefulness of OTHER descriptors when you are using shunts, or other plug in converters. I have plug in temperature, pressure and current devices that output typically in DC Voltage so it would be VERY useful to allow the end user to make adjustments of X Amps per MilliVolt, or X PSI per Millivolt etc.

      Another GREAT feature would be to allow Logging from within the App. There are many times when it would be advantageous to allow the .CSV file to be created in the App then easily emailed or even uploaded to DropBox for sharing or other uses. I have Apps that do just this and it eliminates the need to pull the meter apart, open the meter and remove the MicroSD card.

      I have times when I may need much faster polling than the actual meter allows, 1 second, but I think the processor and memory in the App will be able to possibly capture in the millisecond range?? This would be great for fast transients and other data gathering and I also assume this would just parse the data from the App once the meter gathers it?? There may be a timing element, but if this is critical, I assume a timing offset and a bench test/adjustment can be made and entered into the App??

      Just some ideas.


    • #15042 Reply

      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..

      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?

    • #15049 Reply

      > 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 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.)

    • #15275 Reply

      I bought the mooshimeter for displaying the batteryvoltage and current in an electric car.
      I bought the Mooshimeter for this use, but i cannot use it.
      Please add this feature.

Viewing 6 reply threads
Reply To: DC External Shunt mV Ratings & Calibration
Your information:

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

The reCAPTCHA verification period has expired. Please reload the page.