Best Method to Download Data from a datalogger?

A minimum cost + development time option may be to keep the existing application on the black boxes and replace the PC-side Hyperterminal session with a simple app with a Big Red Button that takes care of the serial session and handles some basic sanity checking of the data.

A slightly jazzier approach would be to do the above ('cuz NOBODY really likes Hyperterminal) but replace the hardwired serial cable with a couple of 802.15.4 dongles, one on each black box and one on the laptop. Could be taken beyond a simple wired to wireless mod, like a small amount of magic in the dongle cases to allow a unique address per truck. The RF modules are relatively cheap, could be intermixed freely with the existing hardwired serial method (so clients won't need to upgrade all of their vehicles at once), and it could be written to be transparent to the existing blackbox firmware (so no field upgrades required).

One option (I'm playing with the dev kit now) are the XBee modules from

A CF card socket, in a truck? Honestly, I don't think so. You want something a whole lot more rugged than a CF card connector's pins. You want something that the users can clean with a fingernail or a compressed-air hose if something got into the socket that doesn't belong there --- and that still works reliably(!) after such treatment.

Just about anything (short of PCMCIA or PCIe cards) would be better than CF there. MMC/SD might be worth a look. There, the biggest risk is that the medium drops on the ground and is washed into the nearest gutter before anyone can bend down to pick it up.

While think about easiness, don't lose sight of ruggedness.

Fastest and cheapest to implement would be a serial to USB converter ala FTDI232 and other manufacturers, minimal hardware change and load another driver onto the laptop.

However note that on some laptops and drivers plugging the USB lead into different sockets SOMETIMES gives different COM port enumerations, which could potentially make it user 'awkward'for running an application.

The other method of the Viniculum and similar has already been mentioned but means probably more host software to change how you deal with a file rather than a serial stream. Unless you have two parts of the application already (i.e. download to file and analyse file).

-- Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services GNU H8 & mailing list info For those web sites you hate

As long as you're not the opposition :) I would recommend that the absolute easiest way is not to bring a laptop to the truck. If you use an SD or miniSD under a suitable protective flap (could be magnetic) then all they have to do is pull out the old one and replace it with a blank one. That way there are no magic tricks or recalcitrant microslop laptops to deal with. The pulled cards are simply collected and brought back to the office for processing directly onto a card reader (use FAT16 formatting).

If you really want to make the cards rugged or perhaps less fiddly you could mount these into their own mini-module and if you are really keen there would be nothing stopping you from using a cheap micro to interface to the SD and cut down the number of pins needed for a rugged connector. In fact the SD module could look like an I2C device so you would only need 4 pins max.

BTW, if your memory requirements aren't all that great you could just use I2C EEPROMs which come in 64KB capacities in 8-pin SOIC. Stack up to

There is also the RF approach as mentioned but once again it requires a laptop (laptops and truck environments just don't mix).

I had a very similar problem with an industrial boiler control where the old method was to use a laptop with an IrDA dongle to transfer data. I started a thread on it about a year ago called "Upload Options" or similar but I can't find it in google.

I went through the various option and, because I have a big chunk of data to shift (16Mb), then I decided to go the MMC route and have been pleased with my choice. If you don't have much data and can handle a bit of extra cost and some IT issues then BlueTooth could be a sensible method but you could be faced with a row of ten trucks all claiming to be truck number 1 and no way easy way to tell them apart. However, this is an implementation issue not a design problem.

MMC is cheap as chips (with small cards) and has no licensing issues which is one of the things that appealed to me. Bear in mind that, if the cards are accessible from outside the vehicle then kids will find out and steal them. Don't put it past the drivers not to "borrow" them for their digital cameras either. I have designed my system not to start up without a card in it so anyone pinching them will have a lot of explaining to do when the boilers don't start up!

Something else you may want to consider in your decision is whether to use a FAT filesystem on your data card or not. If the clients could pull out the data card at any random time, or if the system could ever reset due to insufficient power (e.g. when starting the car in cold weather on weak batteries), a FAT filesystem can easily be corrupted.

A standard card with a standard FAT filesystem might also be tampered with by the driver, in order to destroy any evidence of bad behaviour (this may not apply in your case)

A journalling filesystem could be made more robust against such interruptions.You could upload the new data in an unused part of the flash, then verify it, and mark it valid. If this process was interrupted, simply find the same spot, and try it again.

Do your users a favor and use ZigBee. They'll be happy if there's no wire to plugin.

Got a hammer in your hand, and looking for nails, eh? He merely has to add an RF module and wait for the rest of the universe to support ZigBee. Automotive environments are fairly RF hostile, too. Removable flash media is the right thing to do here.

Your solution sounds rather like the ultimate sort algorithm, which can sort an arbitrary number of items in linear time: Distribute the items randomly. In at least one parallel universe, this must result in a perfect sort. That is the only universe you care about. So the algorithm is: Distribute items randomly. Check if they are sorted. If not, destroy the universe.

Agree, ZigBee is overkill.

GPS, CB and Plain Old Radio are RF too, but you do need to plan your EMI and antenna.

Or a removable module with RF and Flash.

I would look into the ISM band (434 MHz) RF transceiver, they can go upto 200K Baud in theory. In particular, we are looking into the TDA5100/5210 or TRF6903 for such application. FSK should have better noise immunity for auto environment.

You guys all have really great suggestions.

To further clarify my situation. These truck drivers DON'T want to bring a laptop onto the field. Which is why I was thinking about using some sort of removeable flash storage. Reading through your suggestions, seems like I was on the right track. I already have flash RAM inside the black box. So the plan is to have the client download the data onto a CF card once every few months.

Now the question is... how do I start?

I've only been working in this industry for a year... and I have no previous experience with ANY type of hardware design.

I've been googling for the past week... and only found CF card adapters for the PC or linux hard drive replacements. I see all these vocabulary: 'Compact Flash Controller.... Compact Flash Adapter... Compact Flash Connector'

All that vocab means nothing to me. I don't know if I only need one of them or all of them! In most cases, I don't even see a datasheet attached to these products. Am I simply using the wrong search criteria?

Is there someplace I can go to read up on HOW to add a compact flash functionality to my embedded application?

Could anyone please suggest a book for me to read to buff up on my general embedded design skills? Or maybe a website? You guys all seem to know what you're doing... how did you acquire all this knowledge?

I have been trying to figure things out on my own... but I'm totally in the dark... This is so frustrating! :-)

-Mercy

Correcton: I meant MMC or SD cards not CF cards :-)

You need three things:

1. Physical and electrical interface from your device to the card. This means a connector and possibly a voltage regulator and level-matching electronics, depending on your target system.
2. Low-level read/write code to access your flash media at a sector level.
3. A filesystem. FAT is commonly used in this type of application, although it is not very robust. I pointed you to a URL where you can obtain a free FAT implementation to use however you wish. As long as your firmware is written in C, this is a "plug and play" solution.

CF and SD/MMC are approximately equal in terms of software complexity. SD/MMC wins on overall difficulty, however, because the electrical interface is less complex (in particular, fewer pins are required). That is why I suggested it. Oh, and it's easier to hand-prototype, for the same reason.

Read the MMC datasheet at . Actually, maybe you should read the SD datasheet as well.

If you are still sufficiently out of your depth after reading this material and googling for something like "interface mmc to 8051" then I suggest you outsource the project.

Thanks Larwe!

That was very very helpful :-)

-Mercy

I'm not sure what sort of data logging you are doing, but the best once I have every used for analog data logging is the Lascar one,

It only costs =A339, 32Kbytes FLASH, usb interface and very easy data display software.

Lyn

Mercy wrote:

I think the OP wants 10 channels, not just one as in this device.

If the amount of data you want to extract from the datalogger is in the region of 10s of kB you might consider SRAM based iButtons such as the DS1996 (8kB). The data could be split up into a few of the iButtons if it doesn't fit into one. The mechanical interface is as rugged as you're likely to find.

Or try the Ferric RAM (FRAM). As fast as sram and non-volatile as flash. I am still waiting for some 32K bytes sample chips to arrive anytime now.

I've used the Ramtron FRAMS in the 32KB size and S08 package. I didn't need the non-volatility, but I did need a fast, SPI-accessible RAM of significant size. I used two of them and a bit of logic to create a dual-port buffer between a low-power collector and a higher-power logger with more RAM and a hard disk. (10 channels x 16 bits x 120Hz CONTINUOUS for about 6 months on an average current of 14mA.) I had to buy a hundred to get them about a year ago---and will have only used about 30 by the end of the year. One of the advantages of a high- margin niche product is that you can make those purchases without getting ulcers.

Mark Borgerson