Page 2 of 5

PostPosted: Fri Jan 06, 2012 3:33 am
by kareno
I've been planning for years to make myself a tiny Linux computer for just the sort of data logging you mention (and other uses :)

No monitor needed - just a console on a serial port (or even Telnet into it). Switching the logging destination to a network drive, USB stick, hard disk, whatever requires only a trivial change.

A lot of consumer items have little Linux PCs in them now so why aren't I using one...?

Come to think of it, I am - I have one of those little Viglen MPCs (see attached image)

Gary - do you have a port of your webcam-to-NBTV-audio app that runs on Linux? If so I'll give it a try!

PostPosted: Fri Jan 06, 2012 10:42 am
by M3DVQ
The raspberry-pi project will find many uses in the "do some data logging while consuming a small amount of power" field too I expect.

PostPosted: Fri Jan 06, 2012 7:05 pm
by AncientBrit
Steve,

Might be worth having a look at EPE's site

http://www.epemag3.com/index.php?option=com_docman&task=cat_view&gid=70&Itemid=38

Select 12-2011 then download picnmix-stereo-audio.src

In the Dec 2011 mag there was a brief article on using a dsPIC33 to playback stereo 44.1 WAV files making extensive use of a subset of Microchip's Application library, MD Drive File system.
Have you investigated the library?

Or are you set on using SD drives?

The author does say that even with that chip running flat out it's only just possible to achieve playback in the time available
It's written in C and there is no provision for recording though.

He uses DMA for the transfers,
See src, main.c for the main prog.


Cheers,


Graham

PostPosted: Fri Jan 06, 2012 8:24 pm
by Steve Anderson
Thanks Graham, I hadn't come across that site and I'll have a look at the download shortly.

Well, I'm a little mystified why there was mention of this contention of time. I don't know what speed he/she was running the PIC at, but (in time) I'll be running this at 12.288MHz instruction rate, i.e. a Fosc of 49.152MHz. (A 12.288MHz crystal with the x4 PLL engaged). Therefore an instruction time of 81.4ns each. That allows 256 instruction cycles per 48kHz sample...which I would have thought enough as long as you don't waste too many cycles on calls, returns and loops. And in the case of 18F devices, two-word instructions, e.g. use 'bra' rather than 'goto' for local jumps.

If you're going to use C for coding you're already at a disadvantage, that's why I've stuck with assembler. But examining C code can give you an insight as to how others got around a problem.

Yesterday I did spend a few hours on this but found myself going backwards, so I quit early for the day.

Today a few more worms have crawled out of the woodwork, and again referring to the SDA's own data was of not much help. There are so many variables to consider and information that is not concise. That includes info on the 'net too. (Surprise, surprise).

I chose SD cards as they're small, have low power consumption, easily available and I have a clutch of them already.

So at this point I cannot claim any stunning progress, but I'll keep plugging away at it.

Steve A.

PostPosted: Fri Jan 06, 2012 10:48 pm
by AncientBrit
Hi Steve,

I thought I'd mention the site; wasn't sure of any commonality between SD and MD.

You might find something of use,

Cheers,

Graham

PostPosted: Sun Jan 08, 2012 4:13 pm
by Steve Anderson
Progress...All V1.xx cards (up to and including 2GB) initialize and read sectors/blocks correctly. The SD card 'Test-Bed/Fixture' unit I posted in this thread last Sunday (Jan 01) has proved absolutely essential in diagnosing the correct sequence of command structures required. Thank you W.Molesworth.

The clock speed after initialization at approximately 100kHz has been increased to 12.288MHz and all cards behave correctly.

The command sequences are not that complex, they just have to be done correctly. The next step is to provide the same for V2.xx cards (SDHC) for 4GB plus. Basically the initialization is the same as V1.xx, but with a couple of extra steps.

Once through that it's on to writing...and that's where the fun will start I suspect!

More anon.

Steve A.

PostPosted: Mon Jan 09, 2012 3:12 pm
by Steve Anderson
More progress,

All V2.xx cards (SDHC) I have initialize correctly and sectors/blocks can be read...however I only have one example, a 4GB one....I'll have to "acquire" more.

Even so, 4GB is an awful lot of data for a logger and is about six hours of CD quality stereo audio or NBTV...on one little card with no moving parts and uses less than 300mW. Nirvana!

Now the fun starts...writing!

Steve A.

PostPosted: Mon Jan 09, 2012 6:49 pm
by Harry Dalek
Steve Anderson wrote:More progress,

All V2.xx cards (SDHC) I have initialize correctly and sectors/blocks can be read...however I only have one example, a 4GB one....I'll have to "acquire" more.

Even so, 4GB is an awful lot of data for a logger and is about six hours of CD quality stereo audio or NBTV...on one little card with no moving parts and uses less than 300mW. Nirvana!

Now the fun starts...writing!

Steve A.



Hi steve now i know what your up to! your next monitor will have a sold state video recorder player....now you know this is the wrong way to go !
you need a geared motor a cylinder some tin foil and a a needle connected to a voice coil and a valve amplifier this will give you a good 2 seconds of very poor nbtv if you are lucky :wink:

PostPosted: Mon Jan 09, 2012 9:11 pm
by Steve Anderson
Yea, you're right Harry, I do need to get to grips with the mechanical aspect of NBTV. Others have pointed this out in the past.

I have shuffled some mechanical items up into higher priority on my 'NBTV To Do List' but when I'll actually get to them, who knows?

Steve A.

PostPosted: Tue Jan 10, 2012 5:34 pm
by Harry Dalek
Steve Anderson wrote:Yea, you're right Harry, I do need to get to grips with the mechanical aspect of NBTV. Others have pointed this out in the past.

I have shuffled some mechanical items up into higher priority on my 'NBTV To Do List' but when I'll actually get to them, who knows?

Steve A.


No worries steve....do you still have that Aperture drum that looked like a nice build...
i am very curious what you would come up with once you do one ..you need to be complete !

:wink:

PostPosted: Tue Jan 10, 2012 7:08 pm
by Steve Anderson
harry dalek wrote:...do you still have that Aperture drum that looked like a nice build...


Yes, I still have it, it's been festering on my shelves for the past three years at least and has acquired serious case of Aluminium Oxide. Remember that chemical reactions double in speed for every 10°C increase in temperature. With an average daily temperature of 30°C and the humidity here, everything corrodes in the time it takes to go to the bathroom.

I wasn't thinking of resurrecting that, rather starting afresh. The sync and motor-control issue being the bug-bear (US-speak, Booger-Man) of NBTV which needs some serious investigation.

Karen O has expressed an interest in having a crack at it and I hope she does, for what I'm working on within this thread is not going to be concluded any time soon...it is software after all.

I have 'promoted' this sync/motor-control issue to the next thing I intend to tackle, I may fail, Karen otherwise. We'll see. Either way, collectively with everyone's input and feedback it should be do-able. I can't see any reason why not.

Steve A.

PostPosted: Tue Jan 10, 2012 8:29 pm
by Harry Dalek
Steve Anderson wrote:
harry dalek wrote:...do you still have that Aperture drum that looked like a nice build...


Yes, I still have it, it's been festering on my shelves for the past three years at least and has acquired serious case of Aluminium Oxide. Remember that chemical reactions double in speed for every 10°C increase in temperature. With an average daily temperature of 30°C and the humidity here, everything corrodes in the time it takes to go to the bathroom.

I wasn't thinking of resurrecting that, rather starting afresh. The sync and motor-control issue being the bug-bear (US-speak, Booger-Man) of NBTV which needs some serious investigation.

Karen O has expressed an interest in having a crack at it and I hope she does, for what I'm working on within this thread is not going to be concluded any time soon...it is software after all.

I have 'promoted' this sync/motor-control issue to the next thing I intend to tackle, I may fail, Karen otherwise. We'll see. Either way, collectively with everyone's input and feedback it should be do-able. I can't see any reason why not.

Steve A.



Steve festering on shelves yes know what thats like ! but nothing like that
the oxidation problem ...you'd have to run a voltage in them to keep them safe from what you say.

I think you need your projects in a wooden case or plastic up there .

Thats good on the drum idea i always liked bigscreens aperture drum and you can do the plastic mirror bend to change the aspect ratio ,but your poor now oxide ridden drum was well made i liked the look of it .

I would go plastic for safe keeping ...perhaps you could clean the one you made up and paint it ?

The sync problem is framing yes not picture roll from what i gather reading here and there .....I have no great idea but i was thinking the bar between frames could be used detected via the screen its self ..but i can see it depends on image between and trigger something automatic like holtzmans manual switch speed up slowdown control to do it ...since hes doing it via the eye via the screen i gather sensor either side of a screen should do the same .......?

Any case thanks for the hall effect sensor idea i am very happy with results so far ,i have been remaking the sync circuit for this .

Yes you and Karen could come up with something better i have taken in what Karen said about keeping it simple for my try .

Your SD card project is well beyond me i'd give up and stick to the one in the laptop if i tried to make one !

PostPosted: Thu Jan 19, 2012 2:43 pm
by Steve Anderson
Just a quick non-update on this...I haven't done any further work on these SD cards since the last posting as some 'real work' came in and I had to drop it. I should conclude the 'real work' by the end of this day.

How much time I'll be able to devote to these SD cards is questionable as the next week or so is Chinese New Year here and everything stops for family reunions etc..

My intention is to tidy-up the existing software before moving on to writing to the cards.

Steve A.

PostPosted: Tue Jan 31, 2012 6:38 pm
by Steve Anderson
I've had precious little time to work on this over the past couple of weeks, but when I have I have made some progress.

Now the PIC can read the Partition Table, then the Volume ID, thereby finding the Root Directory/Folder and thence the file sought. It differentiates between V1.xx cards (2GB and under) and V2.xx cards (4GB or more in either byte or sector/block addressing).

It's currently set up only for the FAT32 file system, I may set it up FAT16 for cards under 512MB.

The two screen-scrapes below are of the hex-dump of a text file which is just under one sector in size (512 bytes), The addressing on the left-hand side has now been corrected for the absolute offset within the sector.

The PC here is just a dumb display, it's the PIC that's doing all the translation into a ASCII text-dump. So far the code is hovering around 1kB.

Next to do is following cluster chains via the FAT.

Writing is still a little way away...

Steve A.

PostPosted: Wed Feb 01, 2012 6:34 pm
by AncientBrit
Good progress Steve, well done,

Graham