SparkFun Forums

[kwan3217]

This is to announce the release of Logomatic Kwan firmware, version 1.0 . Available at http://www.mediafire.com/file/zlu3zmfgivz/Logomatic Kwan 1.0.zip. This has almost all of the features promised here.

Share and Enjoy!

[kwan3217]

An interpreter for logs written in SiRF format is here: http://www.mediafire.com/file/ynmjqtittf3/SiRF packet interpreter.zip

This is all Java source code, so you need a Java environment to compile and run it. The main program is org.kwansystems.rollercoasterometer.SirfPacket.java , and you will probably have to modify it slightly so that it reads and writes files in the proper folders for your system.

[MontanaTrout]

Great work!

I have the following question:

1. Is your system limited to SiRF GPS Module?
2. If I need connect a GSM module into the logger, Can I send AT command thr UART?
3. Is your firmware support other interface like SPI and I2C?

Thanks!
Dan

[kwan3217]

1) It is for now. It could be pretty easily modified to handle NMEA, but it doesn't yet.
2) Yes, using command.txt, as long as the command is always the same
3) No, the firmware does not. The hardware has an extra SPI port (aside from the one used to talk to the card) but I don't have any other SPI hardware to test it with. It would be pretty easy to adapt the UART code to handle SPI also, and treat it like a third serial port, but I don't think I will do it.

[MontanaTrout]

I would like to know your firmware can handle more than 2 UART interface sensors or not. my project need hook up 4 UART sensors

[Joe Schwendler]

Chris,

I am a newbie at this type of DAQ work and certainly of coding of any type, however I am impressed by the Kwan firmware you wrote.

Chris - my application is to aquire 0-3.3 v voltage data from six air pressure transducers over a rather long period of time (months) at a slow (1Hz) aquisition rate. I wish to add RTC data to this simple record. It seems like it could be an easy challenge for the Logomatic and your firmware to overcome.

I am interested adding/adjusting the Realtime clock feature you built into your firmware solution. I'd like to have a Date/Time stamp show up on the first column of each record recorded to the micro SD card.

So far, I haven't changed many of your settings as you can see...

UART0 mode=None
UART0 baud=0
UART0 trigger=$
UART0 end=0x0A
UART0 size=64
UART0 timestamp=Y
UART1 mode=None
UART1 baud=0
UART1 trigger=$
UART1 end=0x0A
UART1 size=64
UART1 timestamp=Y
Start Time=20090704000000
GPS Sync=1
ADC mode=Text
ADC frequency=100
ADC binning=100
AD0=Y
AD1=Y
AD2=Y
AD3=Y
AD4=Y
AD5=Y
AD6=Y
AD7=Y
AD8=Y

My record ends up looking like this after running the device:

Logomatic Kwan v1.0 Jul 25 2009 09:43:54
MAM setup: MAMCR=2, MAMTIM=4
SD Card Setup: result=3
MID=2
OID='TM'
PNM='SD02G'
PRV=65
PSN=-1386643301
45 66484 14308 509 4748 4801 23419 23386 0 0
45 66496 14353 487 4760 4674 23417 23407 0 0
45 66496 14452 527 4690 4755 23572 23378 0 0
and so on...
Channels 7 and 8 are tied to ground in this application.

I suspect the firmware is giving me part of the date-time stamp already in column 1 of the record, since I can see that this part of the record increments with respect to time, unfortunately I am just not smart enough to understand how to tune it from an incrementing number to a more meaningful date/timestamp number.

Thanks for any insight you can provide, and THANKS for the time investment you made that allows this hardware to have far more utility for folks like me.

Joe Schwendler[/quote]

[mravilious]

Hi Joe,

it looks like you are using Logomatic in a similar application to me. I would also like to log several analogue channels (0-5V), at a relatively slow rate (10Hz) with a date/time stamp for each reading. I would like it to run for about two months off a battery pack and possibly a solar panel to trickle charge it.

If you get anywhere with it I'd love to hear about it! I'm totally new to all this so I can't really offer anything other than lots of thanks and respect to anyone who can work out how to program the logger!

Mark

[mhough]

Hi Joe,
I don't think the code as I understand it to operate will give you a date and time. Its all in the way you read your data..

You need to set a start date and time then each line in your example will be 1 seconds later.

For example if you import into excel change column 1 to the time your started the logger, then set row two to
=row 1 + 1

[mhough]

Kwan, I just wanted to congratulate you on a fantastic job with your new firmware and documentation. I just wanted ADC function extensions which you provide (the binning is great!), and the GPS stuff will be really great later.. once I get my head around kalman filters..

And a battery Monitor!!!!!!!!!!!!
AWESOME!!!

Sparkfun should give you a gift voucher to their store.

[kwan3217]

Version 1.1 http://www.mediafire.com/?niknzgmdjyn

New Features:

*A few bug fixes and more code cleanup
*GPS sync can now use NMEA in addition to SiRF, so almost any GPS is compatible
*Powersave (Put the processor to sleep in between interrupts and turn off the lights)

Thanks for all the feedback!

Joe: The first column (always 45 for you) is milliseconds from the start of the second. I always run my Logomatic at 100Hz or more, so for me it counts up 10 at a time. Adding a full timestamp for each sample 10ms apart doesn't make sense for me, (it increases the data stored in my use case probably about 30%) as I use the $PKWNL time and load once every hundred samples to record the calendar time.

For you however, it is always giving you the same millisecond count since it is only once per second.

For those of you doing slow rate stuff, you can make version 1.0 or 1.1 do effectively what you want by setting the ADC mode to NMEA. This will basically make the ADC data comma-separated instead of space separated by writing the same data in an NMEA $PKWNA sentence, and will write a $PKWNL time tag and load sentence once per second. Without a GPS though, I don't know that the LPC2148 clock is accurate enough. With a GPS, you will have a ton of GPS data as well as the ADC data you want, so you will fill your card faster.

Or you can do what mhough suggested. Still, the clock won't be that accurate.

Are you using a car battery to make it last months? I am able to get about 15+ hours out of my Rollercoasterometer, without using powersave, but I can't imagine using it for months. Also, I have run the system for 24+ hours (on USB power), but I have no idea if the system is reliable enough to run unattended for months. I know I'd want to check on it every couple of days at first.

I'd be interested to know how reliable it ends up being. On a side note, the LPC2148 has a watchdog timer (restarts the processor if the program hangs for more than X time, can be milliseconds to hours) for improved reliability if it were programmed right. Just another thing for version 1.2, in addition to microsecond GPS synchronization.

[theatrus]

kwan,

Good work!

Can I suggest that you put this up in a github repository (or similar)? Easier to see whats changed, allows forking and merging, etc.

[kwan3217]

Wish Granted: http://code.google.com/p/logomatic-kwan/

Note that the whole repository is about 75MiB, and the vast majority of that is documentation from Philips and ARM about the LPC2148 with its embedded ARM7TDMI-S core. If you only want the code, just get main, lib, and RCData/Logomatic.

[kwan3217]

And a battery Monitor!!!!!!!!!!!!
AWESOME!!!

A note on the battery monitor.

For starters, it's just a voltage, not a fuel gauge. LiPo batteries have a complicated discharge curve, different for each physical cell, and it's difficult to work with.

Also, The schematic shows a simple voltage divider, and implies that the battery monitor voltage is precisely half the actual battery voltage. However, I have found that since the divider has such a large resistance, the input impedance of the ADC needs to be taken into account as well. For me, this means that the input voltage has to be multiplied by about 2.27, instead of 2. I presume this is constant as long as the battery voltage is high enough to run the 3.3V regulator, and keep the chip power at 3.3V. Who knows what happens once the power supply voltage starts dropping?

How to find the constant for you: Measure the voltage from ground to V3.3, which naturally should be 3.3V plus or minus a small amount. It's 3.29 for me when the battery is fully charged. Next, measure the voltage from ground to BATT, and write it down. Finally, run the Logomatic recording AD0 for long enough to get a good sample (a few seconds is enough).

Now for some math. Take the average of the AD0 number, and divide it by 1024*(ADC Binning). Now multiply that by the V3.3 voltage measured above and you have what the battery monitor measured. Finally, the ratio between what you measured on the voltmeter from ground to BATT and the voltage the Logomatic measured should be the constant you are after.

So, for me, I measured 3.29V from ground to V3.3, and 4.20V from ground to BATT. The Logomatic was running at 100Hz (irrelevant) with 16x binning (relevant). I got a mean measurement of about 9186 on the battery monitor. Divide by 16384 to get 0.56067, multiply by 3.29V to get 1.8446. Since the actual voltage was 4.2 at the time, the ratio is 4.2/1.8446, or about 2.27. This means that the bottom rung of the voltage divider is significantly smaller than the top, maybe 800k. Since this is the 1M resistor on the board in parallel with the input impedance on the Logomatic, that input impedance must be about 4M or 5M, pretty high, but not a lot higher than the voltage divider.

A couple of requests from Sparkfun on the next hardware rev.

1) Make the battery monitor voltage divider smaller. 10k instead of 1M resistors will make this much more accurate, (constant of about 2.0001 instead of 2.27) at the cost of 165uA current draw (insignificant next to the ~100mA draw of the whole Logomatic).
2) Give me a separate pin for the RTC battery power. This is the only thing needed to make the RTC truly independent, and put the 32kiHz crystal to good use. With a coin cell hooked to this input, the Logomatic will remember the time across resets and powerdowns.
3) Expose as many of the rest of the GPIO pins as possible.

I realize the latter two requests will require more pins, but it will go a long way towards realizing the full potential of the LPC2148.

[mhough]

Kwan3217,
I had a suggestion for V1.2.

Seeing as the logomaticV2 hardware is designed around a single cell LiPo battery then would it be feasible to code the above explaination into firmware and then add a switch to logcon.txt to enable battery monitor as a % value of either safe working voltage to prevent damage to battery or as total battery voltage.. ie my battery spec says 2.75 min voltage.. which would be a ~75% total voltage.. im sure you get my drift..

Then a variable defined in logcon with low power shutdown value such as 76% (or 0% to disable) that would log "low battery shutdown" then put the LPC to sleep.

Sparkfun: If the 3.3v output pins on the logomatic were controlled via an output on the LPC then they too could be shut down for a soft shutdown.
This would allow further gains in battery life by allowing periferals to be put to sleep when not required then powered up prior to being required.

For the record my constant Ratio is 2.2544 which I calculated on a battery voltage of 3.85 (not full). Perhaps for the purposes of getting this to work nicely for everyone others could also share their constant values to see if they are close enough to ensure it is suitable for all.

On a seperate topic, using v1.1 I have noticed occasionally that I get some periods where the system goes 'quiet'..
When logging AD0 only for determining the above battery values I saw this.. almost a second between valid samples and then it made some attempt at 318.. powersave was active.

650 5306
660 5303
670 5304
680 5306
690 5304
700 5305
318
680 5316
690 5315
700 5320
710 5320
720 5320
730 5318
740 5320

I have other logs for 5 channels that accidently ran for over a few hours and it didnt miss a thing.. adc freq = 500 bin=10 the above was 1000/10

Once again, Kudos to you for a great firmware upgrade and excellent documentation.

Mart.

[kwan3217]

Kwan3217,
I had a suggestion for V1.2.

Seeing as the logomaticV2 hardware is designed around a single cell LiPo battery then would it be feasible to code the above explaination into firmware and then add a switch to logcon.txt to enable battery monitor as a % value of either safe working voltage to prevent damage to battery or as total battery voltage.. ie my battery spec says 2.75 min voltage.. which would be a ~75% total voltage.. im sure you get my drift..

Then a variable defined in logcon with low power shutdown value such as 76% (or 0% to disable) that would log "low battery shutdown" then put the LPC to sleep.

This is a good idea. The main problem is that while I can tell the LPC to turn off, I can't do so for any other circuits that are using the battery. For instance, in my rollercoasterometer, I have a couple of inertial sensors which draw mere microamps, but I also have a GPS which draws ~75mA, the same order of power as the whole Logomatic. I can't tell it to turn off, so...

Sparkfun: If the 3.3v output pins on the logomatic were controlled via an output on the LPC then they too could be shut down for a soft shutdown.
This would allow further gains in battery life by allowing periferals to be put to sleep when not required then powered up prior to being required.

As you noted, this requires a hardware change. Another possibility is that if whatever peripheral is commandable, it can be told to shut down via the serial connection. So for instance, when the system decides to shutdown, it sends a shutdown message to the GPS first, then when it receives an acknowledgement, it shuts itself down. This is possible, but pretty hard to do even with one type of GPS, and really hard to generalize to all possible devices.

On a seperate topic, using v1.1 I have noticed occasionally that I get some periods where the system goes 'quiet'..
When logging AD0 only for determining the above battery values I saw this.. almost a second between valid samples and then it made some attempt at 318.. powersave was active.

I have other logs for 5 channels that accidently ran for over a few hours and it didnt miss a thing.. adc freq = 500 bin=10 the above was 1000/10

I've seen something like this, it seems to have to do with one of the buffers filling up. The ADC interrupt handler writes packets to the ADC buffer, which eventually is drained to the SD buffer and written to the card. If the SD buffer ever fills up, both the ADC buffer and SD buffer are cleared and if the system is writing ADC packets in NMEA mode, the system reports an error by writing a $PKWNE packet. Depending on how many channels you are recording, there could be hundreds of samples in the two buffers when they are flushed, which would explain the gap you see.

I don't know why the buffer is getting so full, but I noticed that when it happens to me, there is a lot of UART traffic as well, so it may just have to do with the system being overloaded. If it really is overload, I don't think that anything can be done about it. It doesn't seem to me like your system should be getting overloaded though...