uALFAT

[BCJKiwi]

Have only found one reference to these units with a search.
Is there anyone else with comments on the use of these with PICAXE.

You may have noted my experience with VDrive2
http://www.picaxeforum.co.uk/showthread.php?t=8013
and am looking to evaluate alternatives.

http://www.ghielectronics.com/realdemo.php

Thanks

 

[demonicpicaxeguy]

i think we may all be in some kind of endless loop with these modules that are supposed to allow us to read and write to sd cards,mmc cards,usb memmory sticks

i haven't had a module that has worked as advertised, usaully testing only seems to be done on one brand of card and because it has worked on 1 card it's considered a working design

from experience with now 12 different sd cards of varying capacities, almost all of them don't follow the "sd" protocol to the letter at all a classic example is one of my sandisk cards,
acording to the datasheet the initialisation is supposed to be done at 400khz or below, in reality it won't initialise at anything over 350khz some cards it's 100khz and below or nothing yet the standards specify 400khz

i don't imagine the usb sticks to be vey much different as far as following any standard goes and i suspect that we'll keep having problems getting these modules to work as advertised

my advice before wasting anymore money on them is to try the vdrive with a genuine kingston branded stick, generally kingston stick to the standards the closet followed by sandisk,

the other problem we have is that you go into your local electronics shop and purchase a kingston or sandisk card and naturally you'd like to assume your getting a genuine card and not a rebranded one it's usaully the latter if it's a cheap one

 

[BCJKiwi]

I don't think the issue with the VDrive2 has anything to do with the media.
My testing has been with USB only, not SD/MMC
I have tried Imation, rundisk and noname USB sticks from 16Mb to 1Gb. All work fine with serial, none work reliably with spi.

The issue for me is hspi, not the media.

The uALFAT while more expensive than the VDrive2 appears to be more mature, has a much more sane command and response structure and the documentation appears much better. They also claim (in a product comparison) that their device has much faster data transfer.

So the question for me remains, has anyone practical experience of the uALFAT devices - either SD or USB?

 

[profmason]

Vdrive2

Sorry no experience with the part you listed.

However, the Vdrive2 works well enough as long as you don't want much in the way of file management. We have a USB data logger based on a 28X1 and a Vdrive that has been logging data (Voltage, Current, Temperature and Pyranometer) off a solar panel for about 4 months. It creates a series of sequential text files that contain column delimited data.

Here is a link to my preliminary write up:
http://profmason.com/?p=368

As soon as finals are over, the students should give a much more detailed writeup with the final code.

We have had the best luck using Kingston sticks, but the biggest problem is being sure to close the file appropriately. It takes a long time to close files. If files get to large they won't close correctly and data will be lost. It is better to segment the data into approximately 16K files.

good luck!
mmason

 

[BCJKiwi]

Thanks for your comments.
Looked at your write up and see it is using hserial.

As advised here
http://www.picaxeforum.co.uk/showthread.php?t=8013
the specific issue is with SPI.

I actually posted sample hserial code based on technical's samples in the code snippets section. Unfortunately in my project the only hserial on the 28X1 is already committed to another device.

 

[Michael V]

Yet another storage device

Hi Kiwi,
I'm am also interested in data logging. In my project i was planing to carry a laptop computer into a coal mine to download the data, so removeable storage eg usb stick or SD card is a very desirable thing. Also, in the Forum there were some horror stories about the time it would take to download huge amounts of data from the Eeprom chips.

In searching this forum i found an old october 2004 reference to a device from www.roguerobotics.com in a thread called "Flash Card" Hippy made some good comments about it back then, they would probably still be valid now. Also, there were some horror stories about the time it would take to download huge amounts of data from the Eeprom chips.

I also found a thing called a "Logomatic" from
http://www.sparkfun.com/commerce/product_info.php?products_id=752 which over here in Aus you can buy from www.oceancontols.com.au. I just ordered one today for $69 AUD which would be abound 25 UK pounds. This seems to be similar pricing to the Vdrive and the uAlfat, and the rogue robotics uMMC unit is available here in Aus from www.robotparts.com.au for $65. So i guess it then depends on what else you want to do, and how much flexibility (and complexity) you want to have in writing code.

For me one attraction to the Logomatic product was that in default mode it would just log anything you sent to it in serial mode at TTL or RS232. Also it works at 2400 baud, which is the Picaxe default, so one less worry. The Picaxe "Serout" command and appropriate delimiters should be all that i would need to make a data logger out of ANY Picaxe, including the 08m. However, i will be recording event time also, so i need at least the 18X for the clock.

I plan on analysing the data using Microsoft Excel, which can open a delimited text file up to 65,000 lines in length. That's a lot of data. From a data logging perspective it means i can log multiple (256) fields of data once per second, and keep going for 18 hours! Or data every minute could be logged for over a month.

If i read the data sheet there is a whole lot more this thing can do, it even has a/d converter channels, on board power supply, can generate multiple files, options for the type of data, all through editing a simple text file that lives on the card. I'm just interested in the log file for the moment. You have to preformat your SD card as FAT 16, but your computer and card reader take care of that, and the brochure even tells you how to do it. The instructions in the 6 page brochure seem pretty simple, i guess the "short" length of the brochure was also an attraction!

Also - A bonus (comments from experts please?) for owners of the AXE110 Data logging Module , it seems to me you could use the "Datalink" connector and +5V to interface directly with the Logomatic. (?) If you only want to log data to removable SD card, you only need the serout command, and shouldn't need any of that SPI or Hyper SPI stuff. The EEPROM chip(s) are potentially redundant, and all that code for recording and retrieving from eeprom would also be redundant.

I'll let you know if this little device works.

 

[demonicpicaxeguy]

i've had a bit of experience with the ummc module from roguerobotics , it dosn't actaully work very well at all, getting help for it is a bit like pulling teeth from a gummy bear, and the documentation for it to put it politely is lacking any real detail.....

on the upside recently since my time is no longer taken up blackmailing the nsw health minister to get my wife an operation she should have had serveral months ago but didn't due to lost paperwork/surgeons... i have made some progress in the sd card dept i can get a card to somehwat reliably initialise and i've had a little bit of weird success with reading a sector

 

[hippy]

i've had a bit of experience with the ummc module from roguerobotics , it dosn't actaully work very well at all, getting help for it is a bit like pulling teeth from a gummy bear, and the documentation for it to put it politely is lacking any real detail.....

No device it seems is without its problems. I haven't commented on the uALFAT because I cannot find the references source, but suffice to say that just because some device may perform better in some respects it does not mean it performs better overall.

Comments I've read are that the Vinculum modules tend to perform better and/or longer without reset than some other modules in some cases ( although there may well be opinions of a completely opposite viewpoint, I haven't investigated ).

The main stumbling block seems to be getting SPI to work with the PICAXE, which is entirely different to the VDRIVE not working with SPI. Unfortunately, until someone gets it working and produces reference code, you're on your own. The situation may not be any better with an alternative.

 

[BCJKiwi]

I Have been looking further into the uALFAT data and find that in addition to the standard boards for uALFAT-SD or uALFAT-USB) they also have a simplified data logger firmware (GHI3232) which can be loaded onto the same boards.

This then becomes an 'idiot proof' logger as it does all the file naming and open, write, close file processing automatically. It implements handshaking on some control lines CTS /RTS if you use the serial mode or pin state you can monitor if using SPI mode (no i2c on this firmware).
It will log anything you send to it automatically including adding the commas for CSV files for you.
To minimise delay and write cycles it has a large FIFO buffer which it writes out to the media automatically, or can be set to flush out each second and/or to create a new file as often as you want. The default file name structure uses four letters and four numbers plus extension. The numbers are automatically checked and the next sequential number is used for the next file.

Appears an ideal solution for data logging.

Have requested further information/pricing to New Zealand so it will be interesting to see what the response is like.

@Hippy
Have got the basic SPI working on the VDrive2 as previously advised but the issues with the VDrive2 relate to speed and the resulting complexity and therefore required code space as it is a byte by byte process - i.e. you can't send a string of bytes in a single write but have to do the full write command sequence for each individual byte. Also the bidirectional nature of SPI seems to be unmanageable with the VDrive2 as the responses don't come back predictably.

The uALFAT has a very simple command structure which appears byte oriented rather than 11bit oriented like the VDrive2

There is a fair bit of info on the GHIelectronics.com site including a forum which appears to see a bit of action. I'm not sure what level of references you are looking for but the full command structures etc are included and in far greater detail than provided by FTDI/Vinculum.

 

[BCJKiwi]

There is also a RTC built into the uALFAT - good for timestamping files.
Downside is 3.3 v is required!

 

[tikeda]

That chip has long filename support w/ v3 of the firmware. Nice!

 

[Michael V]

Logomatic Works!!!

Hi All,
I received my Logomatic (referred to earlier in this thread), read the instructions carefully, sent off an enquiry to Sparkfun, and read the guff on the Serout command, and the interfacing circuits in the Picaxe manual re serial communications.

After some experimentation the serout command worked, with "T" rather than "N" . Something to do with the thing having an inbuilt UART in its little NXP LCP2138 chip. All i did was follow the instructions and changed the default speed from 9600 to 2400 by changing one integer in the configuration file on the SD card, which must have already been set to FAT 16 (512 MB card).

	serout 7,T2400,("Boom, ",#boom," ,Temp, ",#temp_byte," ,DP, ",#data3,13,10)

where boom, temp_byte, and data3 were pre defined byte variables.

This code gives me a text file with commas in between the data.

To read and manipulate the file i insert the card into a SD-USB card reader, go into Microsoft Excel (2003), File Open, Go to the SD card reader, select "ALL files" then open the text file. The Excel wizard then detects that is a delimited file, and i then follow the prompt for comma delimited. Then I have a nice excel file that i can manipulate to my hearts content, make pretty graphs, averages, sort data eliminate outliers statistically. An environment much more familiar to me than the world of microprocessor programming!

My electrical connection for this is as per the Voltage divider in The AXE 110 Data logging module and the XBEE connect, i.e the 5V output of the Picaxe is reduced to 3.3V with a 10k/22Kvoltage divider. The CPU of this little thing runs on 3.3V. I don't know if i really had to do this, the Data sheet for the LCP2138, which says the 47 input pins are "5V tolerant" whatever that means. (comments?) But i didn't want the thing cooking like my 28X1 did when i put 12V on the adc input.

So, as per photos, there are only three wires connecting the Picaxe to the Logomatic, Ground, +5v, and the output pin, in this case out7 on the 18X, via the voltage divider.
Sorry about the connectors, that's all i had! You've seen this board in a previous thread, driving an I2C display which i've now mastered, but it now has its own 5V power supply and a few 100nf capacitors as well.

I may end up controlling more, i.e there is a "stop recording" button that can be accessed on the board, and it "starts recording" to a new file when it is switched on. I can do that with a couple of transistors controlled by the Picaxe. It seems you don't need the RS232 interface for the logomatic that Sparkfun suggest.

I guess all that SPI and buffer stuff (other thread) is being handled by the logomatic, which is great, because that is a mystery area for me, and it seems not without interfacing problems. If all i need is one Serout command and to switch the thing off and on, that's what i want and it's worth the money.

Michael