SparkFun Forums

[mhough]

Your right I was only logging 1 channel. No uart. Perhaps there is some kind of "underload" issue going on?


I read an article where I/O pins are used to supply periferals. Which may be another way of using unused pins..

I'm going to try and have a hack at recoding the battery section myself ( as a way of learning C) and so I'll reveal all here later as I get it done..

[kwan3217]

Don't worry too much about turning things off. The Lipo battery control circuit has undervolt protection. It won't let any current out of the cell if the cell voltage drops below a certain level (2.75V for my battery) so it shouldn't hurt things. The circuit will still let current in, so you can charge it back up.

[mhough]

ahh good to know! Little details like that in the sparkfun docs would really help their sales I think.
Gotta sell every little inherent feature of the systems devices.

[keithspg]

Awesome! This is just what I needed.

Lets say that I am not averse to cutting a trace on the board and wiring a coin cell for the RTC. Do you have any idea as to which pin needs power for that to work?

If this were to be done, if I set the time from the txt file, would it be persistent.

Keith[/code]

[point5]

Hi Kwan,

Could your firmware be used to capture time stamped data from sensors such as temperature, humidity, light etc? I'm not experienced with the Logomatic so please forgive me if the answer is obvious !!

Thanks.

[keithspg]

Kwan,

I have been playing with this for a couple days now. I really appreciate what you have done with the software. I noted a couple of things and I do not know if there is any way to fix them in code or not. I want to use this to log over a weekend and have selected the minimum of 1Hz sampling.

I use this logcon.txt file:

Code: Select all

UART0 mode=None
UART0 baud=0
UART0 trigger=$
UART0 end=0x0A
UART0 size=64
UART0 timestamp=N
UART1 mode=None
UART1 baud=0
UART1 trigger=$
UART1 end=0x0A
UART1 size=64
UART1 timestamp=N
Start Time=20090918110500
Powersave=0
ADC mode=Text
ADC frequency=1000
ADC binning=1000
AD0=Y
AD1=Y
AD2=Y
AD3=N
AD4=N
AD5=N
AD6=N
AD7=N
AD8=N

1) The RTC on mine is quite fast. I have it set to average 1000 and I get 150 data lines in one minute. I measure the time from when I switch it on to when I hit the reset button. Is there any way to calibrate the RTC and send that calibration in the config file?

2) The text data format is the best for me as I will be taking this directly into either Matlab or Excel to be able to get a trending curve. Could the Date and time be put into the header or as the first line only in the data file? It is clear that the time is 'every second by the first element in the string, but a time stamp as a start on each data set would be helpful. I do not want to clog the data file with the MNEA header information if possible.

3) I am also getting dropouts. It is apparent what the data that is missing is, but this will be tedious over a large data set to edit the lines. In a minute of logging (150 samples) I have about 2 dropouts (mangled data lines) per minute. It looks like this:

Code: Select all

637 55139 18821 19080
637 55148 18839 19069
637 55152 18831 19093
637 55165 18861 19168
8978 19000
637 55172 18959 19018
637 55189 19055 19026
637 55172 18998 18983
637 55146 18925 19116

[keithspg]

Here I am posting to my own post. I just duplicated the log, but with NMEA instead of Text so that I might see what was going on. It appears that after the data which is glitched, it resets the RTC. I still get 77 samples in a second at 1hz, but the clock time incrementation goes wrong. Is it something with the RTC or something with the data manipulation?

I'll start looking through the code and see if I see anything.

It counts 'seconds': 57,data,58,data,59,no data,glitched 50,data,51

Code: Select all

$PKWNV,Logomatic Kwan v1.1 Aug 27 2009 21:38:55*1F
$PKWNM,2,4,5,1,1,1,1,1,60000000,60000000,1830,1792,01*67
$PKWNC,10,10,14,0,1.4,1,0.3,2,0.2*71
$PKWNL,2009,9,18,11,26,1,21841260,0,7993,0,0,0,0,0,181,0,0,0,0,0,0,0*46
$PKWNA,635,5178,1678,2180*7B
... (snipped log for space)
$PKWNL,2009,9,18,11,26,57,59960273,0,39087,0,0,0,0,0,640,0,0,0,0,0,0,0*41
$PKWNA,635,5140,1576,2206*70
$PKWNL,2009,9,18,11,26,58,59262056,0,41738,0,695571,0,0,0,635,0,0,0,0,0,0,0*75
$PKWNA,635,5140,1578,2206*7E
$PKWNL,2009,9,18,11,26,59,59963094,0,36424,0,0,0,0,0,482,0,0,0,0,0,0,0*49
009,9,18,11,26,50,59957161,0,42312,0,0,0,0,0,527,0,0,0,0,0,0,0*43
$PKWNA,635,5140,1560,2152*75
$PKWNL,2009,9,18,11,26,51,59961830,0,37565,0,0,0,0,0,605,0,0,0,0,0,0,0*4D
$PKWNA,635,5140,1561,2150*76
$PKWNL,2009,9,18,11,26,52,59957032,0,42317,0,0,0,0,0,651,0,0,0,0,0,0,0*41
$PKWNA,635,5142,1562,2159*7E
$PKWNL,2009,9,18,11,26,53,48001224,0,32566,0,0,0,11965811,0,399,0,0,0,0,0,0,0*7B
$PKWNA,635,5144,1569,2194*72

[keithspg]

another reply to my post. I will have to verify this with real data. but is it possible that the code stops the data logging, but when the stop button is pressed it dumps the buffer which gives a duplicate of the last samples? I have a hunch that is what it is doing.

If so, the RTC is accurate at least for the minute I was sampling and it is just duplicating the last chunk.

Keith

[Lostgallifreyan]

This looks really nice (good documentation and clear thinking), so I'll probably try it. I'm very new to this though (only just completed a GPS logger device based on standard Logomatic firmware), and want a failsafe so I can always go back or restart at will if I make errors or get bored/confuzed/whatever..

While I'll try installing WinARM (Don't think Crossworks runs on W98 which I choose to stay with for more reasons than I'll discuss), for now I just want to try the FW.SFE file load via bootloader, as I know I can at least manage that much. To go back I need a copy of the original V2 firmware, ideally with that horrible LOF01.txt and 'saftey' (in LOGCON.txt) spelling bugs and any other small but obvious gaffs cleaned up. :) I looked at SFE's main Logomatic page, searched Google and here, but so far haven't found the original firmware either cleaned up to fix these loose and VERY uninspiring buglets, nor a binary FW.SFE so we can easily revert if we install a different firmware. Please can someone help with this? If you do, it would be worth posting s link to it or some other word of its existence on the main Logomatic page too because I saw at least two posts there or elsewhere that might easily be answered by this file being made available to those who aren't yet ready to risk losing their only secure base while learning a very steep uphill route.


Off-topic, though maybe easily answered so here goes...
Does anyone know why the Logomatic, with standard firmware, freezes after an indeterminate time with the red status LED on, needing power-off and restart to fix? I'm logging from a 5Hz report rate GPS, so around 2KB per second, which ought to be well within capability, and as it sometimes works for 4 hours, other times less than half, I don't think there's anythign specifically wrong with what I'm asking of it. I'm fairly sure the hardware is fine, or it wouldn't work at all most likely. My first move is surely to try a different firmware, hence my main question. I really need a secure and easy way to revert.

[keithspg]

I will look at the code, but I am wondering if there would be a possibility for logging a frequency? If I had a sensor that reported a variable frequency related to a variable that would be cool.

Keith

[Lostgallifreyan]

I will look at the code, but I am wondering if there would be a possibility for logging a frequency? If I had a sensor that reported a variable frequency related to a variable that would be cool.

Keith

It's probably better to convert to a voltage. You might also want to linearise the voltage with a LOG100 IC or similar. Frequency is a logarithmic business (doubling per octave) so you'll run into low-resolution errors at one end of the scale whatever digital conversion you use. So as linearisation is best done with an analog part, you might as well do the frequency to voltage conversion that way too. Both can be accurate, and the basic conversion is dirt cheap. Finding ready-made boards might be tough, but if making one really is troublesome, try looking at DIY audio synthesizer enthusiasts sites, where these problems are often handled. Or at metrology-based systems websites where similar methods are used, but I think the cost will go way high if you go that route.

[Lostgallifreyan]

Ok, further to my first post in this thread (three up from here), I fetched WinARM and set the system path, changed working directory to the Logomatic v2 firmware source, read the GNU make inbuilt help and tried "make -B -f Makefile" and saw a lot of stuff shoot by which I couldn't capture because on W9X there is NO way to capture stderr to a file! But it did make FW.SFE and a lot of other stuff too, so I think I did ok. BUT, how do I KNOW if I did ok, short of blind testing, knowing that at least I won't kill the bootloader? :) I'm like a monkey in the flight deck of Shuttle here.

I'd say this next bit in loud red all-caps if I thought it would help:
Please can someone post a compiled FW.SFE for the original Logomatic V2 firmware so we can revert at will when testing because no matter what we do for ourselves, we cannot (and should not) trust our own work if we are beginners! I can build copies of firmware all day but it won't replace the obvious starting base of using a validated copy provided by someone truly qualified to do it. That way we have something to check against instead of pleading for help.

[Lostgallifreyan]

Update: Jim (and Pete) at Sparkfun has sorted this, the original firmware now includes the file FW.SFE as explained to, and linked to, in the quoted bit of mail below:

>I updated the firmware download
>(http://www.sparkfun.com/datasheets/Widg ... -v2wFW.zip)
>online to include FW.SFE, so that should be taken care of.
>http://www.sparkfun.com/commerce/produc ... ts_id=8627

Links ADDED because it is apparently impossible to make UBB URLs work in that quoted text.
http://www.sparkfun.com/datasheets/Widg ... -v2wFW.zip
http://www.sparkfun.com/commerce/produc ... ts_id=8627


Turns out my first compile was good, it was a bit-match with the new official file. I managed to fix that LOF and Saftey nonsense too and update my board, so I'll try Kwan's firmware soon now I know I can safely try things.

[Lostgallifreyan]

I just tried the Kwan firmware. I like this. :) Thankyou.

For now I'm setting it to do what the original firmware did. My current LOGCON.txt is:

Code: Select all

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

I've verified that the red status LED is lighting up when a fix is had, which is really nice, though when I stow the device under a few floors and a roof and some metal to guarantee no fix, that light stays on. Is this intentional? It would be nice if it also indicated loss of a fix by turning off, or flashing slowly so we at least know it had one once. (Actually fast flashing to indicate estimated fix as current status would also be cool).

Also, I have a query about that Size value in LOGCON.txt for the UARTs. What is that? Everything else is nicely self-explanatory, I didn't even have trouble working out what to write for Mode, or what to do for the line terminations for Windows and DOS, but that Size is still a mystery to me.

(While the PDF documentation is very good it does leave a bit of a gap between newcomer and experienced user that a bit of extra summary in the LOGCON.txt file detail at the end would help with. Perhaps if all options per item were given and summarised, and that section were brought to the top of the file, or a pointer to it placed at top of file...)

[Robertacr]

First off, AWESOME job Kwan! This firmware is saving me a lot of heartache. However I do think I have found a bug of sorts.

Due to space constraints I am logging data only off of ADCs 6-8. The problem is that the Kwan firmware will not allow this (the SFE firmware will). After doing some testing it appears that any N value for an ADC port automatically results in the un-logging (if that's a word) of a corresponding number of ADC ports starting from 8 down. For example, If I try to log ADCs 1-8 but not 0 it will not log ADC8 here's the $PKWMC from that attempt:

Code: Select all

$PKWNC,1600,20,14,1,0.3,2,0.2,3,0.1,4,0.4,5,1.7,6,1.6,7,1.2*75

Here is trying to log ADC 0 and ADCs 2-8:

Code: Select all

$PKWNC,1600,16,14,0,1.4,2,0.2,3,0.1,4,0.4,5,1.7,6,1.6,7,1.2*77

As you can see, with both attempts while it accurately excluded the ADCs I did not want to log, it also dropped ADC 8 which I did want to log. Here are more $PKWNCs and in each case ADCs 6-8 were selected Y yet one or more was not logged due to a corresponding number of earlier ADCs checked as N:

Code: Select all

$PKWNC,1600,16,14,0,1.4,3,0.1,4,0.4,5,1.7,6,1.6*73
$PKWNC,1600,16,14,0,1.4,4,0.4,5,1.7*70

So, for now I am having to log all ADCs to get the ones I want which is not the worst thing that can happen however it is eating up a lot of space. The original SFE firmware handled this with no probs but for some reason this has trouble doing it.

Any ideas on how to fix this in the program? I can hack my way through C but I haven't had luck yet. Thanks in advance!!

Robert