Where to build/install ADC module

[Rich]

Hi MTCAT
Find this in the  start24dsi  file:

Code: [Select]

# Make sure the module file exists.and remove it and the next 5 lines (if through fi)

That section of the script is forcing it to exit before it gets to the  modprobe  command.

[Rich]

Hi MTCAT

... Should I maybe just change my bootlocal.sh ?, namely, remove

/usr/local/bin/start24dsi

and replace with

modprobe 24dsi

Would that work ?, or be an okay way of going about things ?

If your software still works that way, it would certainly simplify things. However, I see the script also creates device nodes
in  /dev/  for each board that it finds. I suspect your software might use those nodes to access the board.

[MTCAT]

Hi Rich,

Oh, okay, thanks (re: circumventing start24dsi), I'll try commenting out those lines in start24dsi and see if it will load up then !

Thanks,

David

[MTCAT]

Thanks Rich, that did it !, it "auto-loaded" all by itself !

I noticed during boot-up a quick message flashed on screen too, loading driver or something to that effect, and now with doing nothing other than type "lsmod", there it is, 24dsi in the list of loaded modules ! Right on !

One thing though, should I just leave start24dsi as;

modprobe 24dsi

or does it matter to change back to,

modprobe ${module_name}

I guess it's kind of academic, but, was the problem with the GSC script that it basically didn't know where to look for the 24dsi.ko file ?

Thanks,

David

[Rich]

Hi MTCAT
You can change it back to  module_name  if you like since it's defined at the beginning of the script as:

Code: [Select]

module_name=24dsi

[MTCAT]

Hi Rich,

Thanks a lot, will do.

I'm playing around with the sample programs, is there a program in TinyCore called "id" already in place ?

I notice in /usr/local/bin that all of the 24dsi "sample" programs, for "rxrate" for example, look like

/tmp/tcloop/24dsi-2.6.33.3-tinycore-686/usr/local/bin/rxrate

The 24dsi has a sample program called "id", that just gives out a bunch of diagnostic info on the board, but, in /usr/local/bin the path to the "id" program that's there is different,

/tmp/tcloop/coreutils/usr/local/bin/id

And running ./id definitely isn't testing the 24dsi, returns info on users, etc.

Similar to the change of "start" to "start24dsi", looks like I should also change the GSC program named "id" to "id24dsi" ?

Maybe even tomorrow I can try to see if the little VortexDX will load the 486 package, after I do all the necessary mod's to the start file !

Thanks,

David 

[Rich]

Hi MTCAT

... I'm playing around with the sample programs, is there a program in TinyCore called "id" already in place ? ...

Yes,  id  is a Linux command.

... Similar to the change of "start" to "start24dsi", looks like I should also change the GSC program named "id" to "id24dsi" ? ...

That would be a good idea. I believe I mentioned the risk of using overly generic names in a previous post.

[MTCAT]

Hi Rich,

I changed "modprobe 24dsi" back to "modprobe ${module_name}, and changed "id" to "id24dsi", and all is well, the "id24dsi" program runs now, the driver loads faithfully, so far so good !

I also made the required changes to the 486 package, namely, the start script modifications, and re-naming id, and then re-squashed that package as well.

As you predicted, the 486 AND 686 packages seems to run equally well on the DX3.

Next step will be to see if the lower power DX will load the 486 package, hopefully will find that out tomorrow !

Then it's "only" the logger program left to get going, which needs ntp and real time Linux stuff (yikes).

Thanks,

David

[Rich]

Hi MTCAT

... Then it's "only" the logger program left to get going, which needs ntp and real time Linux stuff (yikes).

Are you referring to a real time kernel? If you are, what makes you think you need that? If I'm looking at the correct
spec sheet, its features include:

256 K-sample FIFO Buffer
Synchronous or Independent ADC Clocking
Internal Sample Rate Generators
DMA Engine Supports both Block-Mode and Demand-Mode Transfers

That suggests the hardware is capable of acquiring the data and transferring it to your computers memory. If all you have
to do is process the data that's been deposited in system RAM, you don't need a real time kernel.

[MTCAT]

Hi Rich,

That would be great if I didn't need to worry about the real-time kernel, I admit I don't really know if it's truly needed.

From what I understand, a PPS signal is input to one of the serial ports (RS232) to "discipline" ntp, in order to get a pretty good time sync to GPS, down to ~ the ms level.

And then we also collect the PPS signal itself with the 24DSI so that we can further refine relative timing of "events" between two separated instruments, a so called base station and a rover, which can be several miles apart.

So I don't think any of that requires real-time kernel yet ?, but, the logger program basically samples continuously at 200 kHz, saving "events" in 2 or 3 second windows whenever a simple amplitude threshold is exceeded. But on top of that, even if no "events" are found, the 200 kHz data-stream is continuously low-pass filtered and decimated to a 20 kHz sampled "continuous" data stream, which is written out to disk in 60 second chunks, and it's that continuous data stream that I think is synchronized to start sampling at the top of every minute.

Could that be a legitimate "real-time" usage scenario, to ensure that the 24DSI starts sampling at the top of every minute ?

Thanks,

David

[Rich]

Hi MTCAT

... but, the logger program basically samples continuously at 200 kHz, ...

I doubt that. That means the program would be interrupting the OS every 5 uSecs. I suspect what's really happening is
the logger program programs the 24dsi to do something similar to:
1. Take readings every 5 uSecs.
2. Save readings to FIFO.
3. When FIFO fills to a certain level, do a DMA transfer from FIFO to a buffer in system RAM.

The logger program probably processes the data in blocks as it becomes available in that buffer.

[MTCAT]

Hi Rich,

You could be right, one thing I forgot to add, the logger program makes use of a 128 MByte "buffer" in RAM as well,  I think it's in one of the ".rc" files in Slackware, where it's declared, a big chunk of RAM that's dedicated solely for the logger program, so that ties in with your comments I think. This was one of my concerns with trying out an AMD Geode with only 256 MBytes RAM total.

In any case, hopefully the "real-time" kernel can be avoided, just to keep things simpler, maybe it's not really needed.

As I'm sure you can tell, I'm not a super-programmer by any means, I've mostly worked by "proofing" data processing code in Matlab/Octave/Scilab, and then translating to Fortran for speed, the logger program is written in C(++ ?), so it's kind of hard to read from my stand-point. But I do like the simplicity (and power) of command prompt stuff too, hence my enjoyment of TinyCore !

Wish me luck with the DX, hopefully I'll give that a go today, see if it will load the 486 package !

Thanks,

David

[Rich]

Hi MTCAT

You could be right, one thing I forgot to add, the logger program makes use of a 128 MByte "buffer" in RAM as well,  ...

So if the board is running full bore, it will accumulate data at a rate of:
200K samples/sec x 12 channels x 4 bytes/sample = 9600 Kbytes/sec = 9.6 Mbytes/sec.
So your buffer can accommodate 128 Mbytes / 9.6 Mbytes = 13.33 seconds worth of data without overflowing.

Your board produces 24 bit data which only requires 3 bytes. I calculated 4 bytes because dealing with 32 bit data is faster
than 24 bit data. There's also the distinct possibility they actually use a fourth byte to provide additional information, such
as which channel the conversion was performed on.

[MTCAT]

Hi Rich,

I tried out the VortexDX loading the 486 package and unfortunately it didn't work, although it looks like it did load the driver ?, but something else went wrong.

I'll try to describe the bootup verbally.

After;

 "Loading Extensions....Done", "Setting keymap to us Done", "Setting hostname to box Done" then the TinyCore Linux "graphic" screen pops up, and underneath that it said " login[2142]: root login on 'tty1' ", and then right under that "Driver loading: 24dsi...", and then something odd popped up on the next frame, "route: SIOCADDRT: File Exists".

And then the screen went blank for a few slides, and then "Creating /dev/24dsi.0" (that's a zero after the 24dsi.), and then next slide looked like this;

Creating /dev/24dsi.0
Floating point exception
sh: 01: unknown operand
Driver loaded: 24dsi

And then the next slide looked like this

Creating /dev/24dsi.0
Floating point exception
sh: 01: unknown operand
Driver loaded: 24dsi
Floating point  exception
chown: cannot access '/usr/local/tce.icons' : No such file or directory
chmod: cannot access '/usr/local/tce.icons' : No such file or directory

And then next slide is as above, except with a lot of "Floating point exception" scrolling by now, and eventually, I just end up with a blank screen, after which I powered down.

What do you think ? Am I out of luck with the VortexDX ?

Thanks,

David

[Rich]

Hi MTCAT
Remove  24dsi-2.6.33.3-tinycore-486.tcz  from your  tce/onboot.lst  file.
Reboot the machine.
Perform a rescan of the PCI bus:

Code: [Select]

echo 1 | sudo tee /sys/bus/pci/rescanNext load the extension:

Code: [Select]

tce-load -i 24dsi-2.6.33.3-tinycore-486Then run the startup script:

Code: [Select]

sudo start24dsi
If this causes floating point exceptions, then you should probably move on. The incompatibility that prevented compiling the
driver is also preventing its use.