Jump to content

Current/voltage measurement and heat dissipation


esaj

Recommended Posts

Lol. you're right about the direction: I didn't think about that.

I've just had a look at the BMA180 datasheet and indeed it can be an interesting addition since it also measures temperature with an accuracy good enough for this application (0.5 celsius resolution). Anyway I am not sure how the BMA could be used to measure slopes and the wheel til-up at the same time.

I think using 100 data frames per seconds would cause a huge battery drain on the smartphone. For this kind of data logging I think using a local sd card connected to the µC would be a better option.

My original idea about the app was more about a low-frequency logging: the µC would gather data and constantly send aggregated data to the smartphone: for example the app could tell the µC to use 5 seconds time windows and the µC would start sending a frame every 5 seconds with minimum/maximum/average values of each parameter accross the given time window. This is why i started looking at the NRF24L01+ since it can do bluetooth LE.

Of course there would also be "absolute" values (I mean not subject to the time window) like total traveled distance, life time (total number of seconds/minutes the wheel has been powered on), total number of charge/discharge cycles. This kind of parameters would be stored in the µC eeprom/flash to be retained accross power on/off cycles.
Storing to files from the app after doing some work on the data is not a problem at all and creating charts should not be hard.

Oh sorry, there was misunderstanding.

I meant a detailed log system to monitor a lot of things to make a detailed technical review of all possible wheels, something that would be done only for documentation purpose for propspective buyers to compare to know more about different wheels before buying. Such review don't exist so far and I want a logging system to do it, that's why I want things like an inclinometer and a high sampling frequency to have accurate instantanuous power data. For such use, the power optimisation of the android app is not necessary.

What you want is an everyday usage logging system. The principle would be the same as above, but with much simpler implementation : lower transmission rates, less monitored variables, mean values calculated by the microcontroller before transmission...

Of course, we can do both versions, very easily.

Link to comment
Share on other sites

Oh sorry, there was misunderstanding.

I meant a detailed log system to monitor a lot of things to make a detailed technical review of all possible wheels, something that would be done only for documentation purpose for propspective buyers to compare to know more about different wheels before buying. Such review don't exist so far and I want a logging system to do it, that's why I want things like an inclinometer and a high sampling frequency to have accurate instantanuous power data. For such use, the power optimisation of the android app is not necessary.

What you want is an everyday usage logging system. The principle would be the same as above, but with much simpler implementation : lower transmission rates, less monitored variables, mean values calculated by the microcontroller before transmission...

Of course, we can do both versions, very easily.

Hi hobby, this is also what I would like to do. My problem is that I do not know much about electronics, but fairly much about programming, not much experience with embedded  programming, but I guess it is the same. I now have frameworkio up and running so I can escape arduinoes IDE. Also, with frameworkio i can program normal c-code to a large host of different boards, I have an arduino pro-mini that i now have a blinking diode :) so there is far to go. I am waiting for my first set of delivery from banggood to see how it goes with customs etc. if everything checks out I will order some sensors / SD-card and SD-card-holder, but I guess it shoul already be possible to measure the rpms from the HAL sensor as you noted.

If I upload a picture from my motherboard, could you identify what wire I shoul hook up to the arduino?

Link to comment
Share on other sites

Of course, we can do both versions, very easily.

The way I'd approach this is having the app initiate the actual data logging / everyday usage logging. A handshake between the app and the device could be used to negotiate what is wanted, and at what rate. Like "Hello, give me telemetry data every 100ms and other data every 1000ms", and the microcontroller would then measure and send both the datas at asked frequencies. Or to save smartphone battery, they could only ask for the other data at given rate, or if only telemetry is wanted. All the telemetry data would be saved for example with the filename as timestamp of when the "recording" was started (or finished), like 2015-08-02-005510.txt and give the user the option to rename the file at the end of recording or discard it. If not specifically discarded or saved under different name, the file would stay with the original timestamp as name. If you'd want to record the telemetry data for riding up that one specific hill, so you wouldn't need to go through lots of unnecessary data, you could only activate the recording once you're at the hill, ready to start, and log only the climb with high frequency (like 5ms / 200hz), then save it as "uphillclimb-data.txt" or whatever.

The "everyday" riding would then be showed like in Ninedroid or Gotway app or whatever.

Just my 2 cents ;)

Link to comment
Share on other sites

The way I'd approach this is having the app initiate the actual data logging / everyday usage logging. A handshake between the app and the device could be used to negotiate what is wanted, and at what rate. Like "Hello, give me telemetry data every 100ms and other data every 1000ms", and the microcontroller would then measure and send both the datas at asked frequencies. Or to save smartphone battery, they could only ask for the other data at given rate, or if only telemetry is wanted. All the telemetry data would be saved for example with the filename as timestamp of when the "recording" was started (or finished), like 2015-08-02-005510.txt and give the user the option to rename the file at the end of recording or discard it. If not specifically discarded or saved under different name, the file would stay with the original timestamp as name. If you'd want to record the telemetry data for riding up that one specific hill, so you wouldn't need to go through lots of unnecessary data, you could only activate the recording once you're at the hill, ready to start, and log only the climb with high frequency (like 50ms / 200hz), then save it as "uphillclimb-data.txt" or whatever.

The "everyday" riding would then be showed like in Ninedroid or Gotway app or whatever.

Just my 2 cents ;)

I agree about the dual mode of the µC firmware and using two different apps for different purposes: "benchmark mode" for high frequency raw data and "cruise mode" for slow heartbeat with aggregated data and low power usage.

I'm not familiar with the ninebot/gotway/kingsong apps, but my understanding is that these apps do not have any kind of correlation between location, speed, heading and time data from the phone's gps module and data from the wheel. Is this correct? I think this kind of integration is a must. Being able to monitor the battery charging process also would be very interesting.

Link to comment
Share on other sites

We can set up a nice collaborative project if tasks are distributed according to what each does best. Labor division and specialisation is THE thing to do.

I know well how to make hardware and program embedded, real-time, optimised softwares on most common plateforms. I can rapidly design a functionnal module based on cheap and off the shelf parts and make it open-souce if any of you wish (parts cost can be around 10 euros). I can send for free a ready-to-wire module for the app developpers.

Like what is already on bluetooth wheels (Gotway, Ninebot...), data are sent by bluetooth using the ubiquitous BC04 module emulating a serial comm port. I will sent them in ascii lines, comma separated, like what is already with the Charge Doctor. According to Esaj, communication may be bidirectionnal to enable the android/IOS app to change some parameters in the embedded module like switching between benchmark and everyday-use modes. Not a requirement but why not since it takes just a few lines of code in the firmware.

It's up to the android/IOS app to log the data stream into a text file and/or processing it in real time to display relevant information. That's the task of the smartphone developpers. Since there are three of you so far (Esa, cg and gadan), maybe you can think of a way to do it best according to your competency, time and commitment to avoid redundancy, what do you think Esaj ? How about setting up a github repository, or just using this forum's private mails, or even an article on my blog where we can collaborate in the comment section ?

 

If I upload a picture from my motherboard, could you identify what wire I shoul hook up to the arduino?

I can of course. But wouldn't it be better for you to wait until I share my design ?

Link to comment
Share on other sites

We can set up a nice collaborative project if tasks are distributed according to what each does best. Labor division and specialisation is THE thing to do.

I know well how to make hardware and program embedded, real-time, optimised softwares on most common plateforms. I can rapidly design a functionnal module based on cheap and off the shelf parts and make it open-souce if any of you wish (parts cost can be around 10 euros). I can send for free a ready-to-wire module for the app developpers.

I think that is a very good idea, for me making it free software (not to mistakken for gratis) is important, that being said, I would especially preffer that the software was made using a GPL license. I am probably not going to be working on developing app modules, first of all, I have a Jolla phone, so only very few people would be able to use the program, secondly, I prefeer the loggin could happen directly to the SD-card with no phone connected.

I would like to be able to attach display to the module to show voltage/power etc. this means, that the I would suggest making it possible to change the ouput modules, where the one you are refering would be giving serial ascii data to a pin or bt.

Actually, I think it would be nice to make an free and opensource EUC :)

It should also be able to control pedal tilt back (it would be possible to make @esaj wish tilt back curves), wheen to beep etc etc.

(Regarding waiting for my mother board, it might be better to wait for your design, but I might not be able to :P, lets se).

 

It's up to the android/IOS app to log the data stream into a text file and/or processing it in real time to display relevant information. That's the task of the smartphone developpers. Since there are three of you so far (Esa, cg and gadan), maybe you can think of a way to do it best according to your competency, time and commitment to avoid redundancy, what do you think Esaj ? How about setting up a github repository, or just using this forum's private mails, or even an article on my blog where we can collaborate in the comment section ?

I am not really an smartphone developer, my phone belongs in the pocket :), but I am all up for a github repository combined with your blog perhaps for descriptions etc? I must admit that I am only used to closed source development, where the collaboration is done with physical meetings.

Like I said, I think it would be really cool to make a complete EUC (mainboard+BMC+?) but that might be to much for just the four of us to tacke.

So, I think it is a good idea to work out the requirements and task, and then if someone feels for it, they can bid on the task, I have used action item lists before and think it is a really good way to breakdown tasks, but if you know of some better way (better=simple in my opinion), I am all ears.

Perhaps making a project on github gives us the tools already?

 

Link to comment
Share on other sites

I think that is a very good idea, for me making it free software (not to mistakken for gratis) is important, that being said, I would especially preffer that the software was made using a GPL licens

+1 for the free software license, but IMHO, GPL should not be a strict requirement: there are a lot of OSI approved licenses out there: it might be worth investigating which one is best suited for a mixed software/hardware project like this

Perhaps making a project on github gives us the tools already?

Githiub offers a lot of useful tools, but probably at this stage something simpler would be enough and more practical. If we agree, I can install etherpad on one of my vpses to be used for collaboration on the design documents and ideas.

Link to comment
Share on other sites

Like what is already on bluetooth wheels (Gotway, Ninebot...), data are sent by bluetooth using the ubiquitous BC04 module emulating a serial comm port. I will sent them in ascii lines, comma separated, like what is already with the Charge Doctor. According to Esaj, communication may be bidirectionnal to enable the android/IOS app to change some parameters in the embedded module like switching between benchmark and everyday-use modes. Not a requirement but why not since it takes just a few lines of code in the firmware.

Yes, "handshake" was probably too strong of a term, they could be called simply "control messages" to change the logging parameters in the microcontroller side. Also, I would like to see it possible to ask for both data at different rates (like in my example, benchmark data every 100ms and everyday data every 1000ms), so a single software could handle both telemetry logging and showing the current everyday data at the same time. Of course if the "everyday" data can be calculated based on benchmark data, there's no need to differentiate them, in everyday use you would just ask for the benchmark data at lower rate, and the app would calculate what to display based on it.

 

It's up to the android/IOS app to log the data stream into a text file and/or processing it in real time to display relevant information. That's the task of the smartphone developpers. Since there are three of you so far (Esa, cg and gadan), maybe you can think of a way to do it best according to your competency, time and commitment to avoid redundancy, what do you think Esaj ? How about setting up a github repository, or just using this forum's private mails, or even an article on my blog where we can collaborate in the comment section ?

For actual software development, Git or SVN is probably the way to go, I don't care if it's in github or some other service or even private (public internet facing) repository accessible over SSH, but it must be available to everyone at all times. I use either GIT or SVN in my own personal projects against a local repository on my own computer, just so that I have the change histories of the projects and can check even my own changes and compare & possibly roll back if needed.The minute more than one people are working on the same project, you will need version control to handle the eventual file conflicts and such. Also handy for continuous integration & automated testing, although that's probably not needed for this small project.

For design and task listing, I've been mostly happy with Trello, it's fairly lightweight and easy & fast to use:  https://trello.com/  , but am open to other ideas.

 

+1 for the free software license, but IMHO, GPL should not be a strict requirement: there are a lot of OSI approved licenses out there: it might be worth investigating which one is best suited for a mixed software/hardware project like this

Githiub offers a lot of useful tools, but probably at this stage something simpler would be enough and more practical. If we agree, I can install etherpad on one of my vpses to be used for collaboration on the design documents and ideas.

The software-side could be licensed under WTFPL (basically public domain) for all I care, if someone wants to use it in GPL'd project, they can just take it and re-license it, if they see the need to.

To use a more "private" github-repository, you can simply just create a directory for the repository in you VPS and init it empty with command line git, after that everyone with ssh-access and read/write rights there can use it as a remote repository, here's some simple example I pulled off google (just need to replace the file:// -protocols with ssh:// for real remote access): http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/

Link to comment
Share on other sites

 

For actual software development, Git or SVN is probably the way to go, I don't care if it's in github or some other service or even private (public internet facing) repository accessible over SSH, but it must be available to everyone at all times. I use either GIT or SVN in my own personal projects against a local repository on my own computer, just so that I have the change histories of the projects and can check even my own changes and compare & possibly roll back if needed.The minute more than one people are working on the same project, you will need version control to handle the eventual file conflicts and such. Also handy for continuous integration & automated testing, although that's probably not needed for this small project.

I agree that there should be some kind of version controll, I am only used to SVN, by it is supposedly hoppelesly outdated? so GIT is fine with me. (I am also using svn both for my own projects for the same reason you list here, and svn at my work)

For design and task listing, I've been mostly happy with Trello, it's fairly lightweight and easy & fast to use:  https://trello.com/  , but am open to other ideas.

Githiub offers a lot of useful tools, but probably at this stage something simpler would be enough and more practical. If we agree, I can install etherpad on one of my vpses to be used for collaboration on the design documents and ideas.

I have not tried either etherpad or trello, but from the initial look, I would prefeer etherpad since it seems simpler, and that the content is on a server that @gadan controlls

Link to comment
Share on other sites

I am just going to add this :)

I have sealed the compartments yesterday, and today I was going offroad (as much as is possible with my generic A2 :) ) piles of mud, I almost wasn't able to walk where I tried to drive... erh where was I... yeah,

no heat felt on the side with the controller compartment.

Ok, after one hour drive 'walking' the dog today, I must admit that the controller compartement felt hot!

Link to comment
Share on other sites

Sorry about hijacking the thread, but here is something I have thought about

The software on the regulator, could be modularised in such a way that it is easy to change where the data is sent, different receivers could be:

  • Transmit via serial (BT)
  • Save to SD-card
  • Send to internal display (screen diodes etc)

Regarding the sampling, I would think the most modular way is to let all sampled data go into the reciever function, so the bluetooth/serial module is responsible for further processing /subsampling or filtering, in this way it is possible to both save to the SD card at one sample rate, send data to the Phone at another sample rate, and update the on-wheel display at a third sample rate.

If we think further about a completely opensource gyro-cycle, the same modularization could be considered for the power control function, so one can have a fuzzy logic algorithm to controll the wheel, and another can have a normal PID controll algoirthm.

Link to comment
Share on other sites

  • 4 weeks later...

I built a few temp/humidity sensors using the ESP8266. Very easy to use (you can program it in LUA, using a nice interpreter/compile called nodmcu, https://github.com/nodemcu/nodemcu-firmware and its editor environment http://esp8266.ru/esplorer/; or there is a port of the Arduino IDE, so you can use most Arduino libraries, or if you want you can code in C/C++ in the native SDK, with full control). Since the ESP8266 has its own processor onboard, it's a completely self-contained embedded system. My temp/humidity gizmo is literally two pieces: the ESP8266 itself and a DHT22 as a sensor (well, I guess I have to add a power supply, too :) ). Nothing else. My system connects to thingspeak.com using my home wifi (super simple to connect, it handles any wifi glitch by itself) and sends updates every 2 minutes (I have 5 sensors around the house).

It can host a web server, but it has limited memory. It should be possible to use an external SD card filesystem, but it'll quickly add complexity. In theory it's possible to build a self-contained solution with the ESP8266 and sensors, collect all data, and present the data to any device via a Web interface (using the ESP8266 as an embedded web server). The only thing I have not done yet, is to store/retrieve files from an SD card... checking on the various ESP8266 sites, it looks as if there already are solutions for this, like http://www.esp8266.com/viewtopic.php?f=32&t=3558 . The only risk is to run out of I/O ports. If you consider playing with ESP8266, the best one is the ESP-07 (it has a built-in ceramic antenna and can use an external IPX antenna), with its carrier board (to simplify prototyping; the ESP8266 using a 2mm connector).

Please keep in mind it's a strictly 3.3V device, and none of the I/Os is 5V tolerant. They burn much more easily than anything else I used until now :angry:. Good thing that they cost nothing, so now I always have a small stash ready for anything (I order from Aliexpress, and it takes 2-3 weeks for the modules to arrive)

Aliexpress has the best prices, and I used these seller before: http://www.aliexpress.com/item/5pcs-ESP8266-serial-WIFI-module-adapter-plate-Applies-to-ESP-07-ESP-08-ESP-12/32276265629.html and http://www.aliexpress.com/item/ESP8266-serial-WIFI-model-ESP-07-Authenticity-Guaranteed/32220241193.html 

 

 

 

Link to comment
Share on other sites

Sorry, that is true. It is an AC meter.

Anyway, I suppose that DC meters without shunts must exist, since clamp meters can measure DC currents without shunts. It is the same physics theory, AC or DC.

...yes, found it: http://es.aliexpress.com/item/2in1-Dual-display-Voltmeter-Ammeter-DC-0-100V-20A-Digital-Voltage-Current-Meter-Current-Transformer/32368724889.html

 

Just because I have a pathological urge to be annoying with technically meaningless minutiae :), the theory behind AC and DC ammeters is different, one being based on a transformer (AC), the other on a hall effect transducer http://www.electrotechnik.net/2009/09/how-does-dc-clampmeter-work.html. Granted, both have to do with the same concept of current and magnetism... so physics is the same, even if the transducers themselves are completely different

Even if the seller on Aliexpress calls that a "transformer", in reality they use a hall effect sensor (and those exist in either "thru the hole" or "clamp" versions). Incidentally, their price is very good, so worth considering it

The actual reason why I point this out is that, if anyone wants to build a high current ammeter, it's always preferable to use a hall effect sensor calibrated for the proper range, than a shunt (also much easier to calibrate: hall effect sensors usually have trimmers, the shunt must be physically modified. sometimes very painfully). Size-wise, it's also easier to fit a 90A hall sensor than a 90A shunt (huge). 

http://uk.rs-online.com/web/c/automation-control-gear/sensors-transducers/current-transducers/?sort-by=P_breakPrice1&sort-order=asc&pn=1 

There are also devices on eBay that can be soldered inline, and would probably deal with vibrations better (built like these http://machinedesign.com/sensors/sensor-sense-hall-effect-current-sensors). The nice thing is that they are usually calibrated properly in the factory, unlike the cheap Aliexpress/eBay shunts that are truly horrible. 

Here's what they are based on http://www.allegromicro.com/en/Products/Current-Sensor-ICs/Fifty-To-Two-Hundred-Amp-Integrated-Conductor-Sensor-ICs/ACS758.aspx  and sell on eBay for $3-4 for a 50A or 100A version. Please note that there are unidirectional and bidirectional units, so for an EUC I would choose bi-directional (in order to measure regen braking)

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

I use LEM LTS-25-NP as the current transducer for my IPS 122 a year ago. It's not recommended because a battery wire has to be cut and an external 5V power supply must be provided.

For Gotway MCM2 and MSuper, I made a easy plug-in shunt. Thick manganin wire is taken from a 10A current meter, cut in the middle, parallel soldered into a pair of XT60, calibrated by precision power supply(HP6632A and IT6322) and 6.5 digit multimeter (HP34401A).
I use GRAPHTEC GL220 data logger for data sampling and made some tests. At this point, I confirmed that Gotway's reading of current is very much overstated which I suspect for a long time.

ATransducer.jpg

transd2.jpg

transd4.jpg

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...