General TC > General TC Talk
Building Another Logger
MTCAT:
Hi everyone,
Happy New Year!, has been a while, I've had my one real-time TinyCore logger going for sometime now, thanks again for all the help!, and it's been working super well, I still need to get the C-program to load temperature readings from a file in order to see the CPU heatsink temperatures inside the GUI though.
But, I'm taking the first tentative steps in building a second logger and I'm thankful for any advice/recommendations the forum may have.
I've made copies of my existing, fully functional TC setup on my boot pen drive (with dd), so I have that already ready to go. Would it be "wishful thinking" to think that I could assemble the new PC104 stack as per the existing functional one, hook up the U-Blox EVK-M8T for timing, hook up the temp sensor, insert the 128 GB CF-card, plug in the dd copied boot pen drive, and everything would "come up" properly and work?
Or, do you think I need to do some staged install procedure where I get individual parts of the system going first, like get the ADC working with the module being auto-loaded, get the timing working, then get the temp sensor working, I do need to also update the BIOS to get my LVDS display to work, and the existing fully functioning receiver also has Lubuntu 16.04 installed on the CF-card on which Rich helped me setup a symbolic link to save acquired data to. Unfortunately I can't find the Lubuntu image file and need to contact WinSystems to see if I can get that still, although I don't ever use the Lubuntu install(yet), it might be useful down the road, maybe, for getting data off the receiver though because the GigaBit ethernet port works in Lubuntu, right now, in TinyCore, getting GB's of data off the receiver over USB is pretty slow, I'm only getting about 10 MB/sec even though it's supposed to be 2.0 speed, so takes like an hour or more sometimes to get one days worth of data off the receiver, need to try the 100 MBit ethernet connection in Tinycore and maybe that will be faster than the USB ports, but the Gigabit ethernet would be even better, I think that would be the only reason to keep Lubuntu hanging around.
Thanks,
David
MTCAT:
Hello again everyone,
As per the original install, I copied the compressed Lubuntu 16.04 image file onto the 128 GB CF-card with HDDRawCopy, with Lubuntu booted up, I did a bit of poking around to find the address of the 100 MBit ethernet port and my router, I also found the UUID of the CF-card, and then updated the BIOS for "direct-drive" LVDS operation of the PixelQi screen, and lastly changed serial port one to 9600 bps (for U-Blox module) and made the USB the first try for booting.
I connected my U-Blox GPS module RS232 output to serial port one, and +5V power of course, and plugged in a digitemp USB temperature sensor, plugged in my cloned TinyCore 3.8.4 with real-time patch, and powered on the Vortex DX3, unfortunately it didn't boot and hangs up after the 10 second "pause" count-down is completed.
Trying again and hitting Tab in that screen shows me some (all?) of the content of extlinux.conf (I think) where a lot of UUID's are seen, I think for the boot pen drive and the CF-card, I need to change these UUID's. I do know the UUID of the CF-card, but would booting up Lubuntu, plugging in the TinyCore boot drive, and typing "lsblk -f" work to get the UUID of the pen drive as well?
Then could I edit the extlinux.conf file on my Slackware Linux desktop entering in the new UUID's for the new CF-card and pen drive? Does that sound correct?
Thanks,
David
Rich:
Hi MTCAT
UUIDs are unique for each device. Once you know the device
name of the drive, you can run lsblk against it for its UUIDs.
You may need to use sudo for this. Here's what happens
on Tinycore with and without sudo ...
without sudo:
--- Code: ---tc@E310:~$ lsblk -f /dev/sda
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
|-sda1 /mnt/sda1
|-sda2
|-sda3
|-sda4
|-sda5 [SWAP]
|-sda6
`-sda7
--- End code ---
with sudo:
--- Code: ---tc@E310:~$ sudo lsblk -f /dev/sda
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
|-sda1 ext4 TC10 543cac60-3224-4cab-b1d5-008407dd9ce8 /mnt/sda1
|-sda2 ext4 TC10_backup 22559ae7-7e12-4a3b-9efa-6f8c8a9a8a6a
|-sda3 ext4 bedfc958-a562-4225-ad9d-cf150e7cdb4e
|-sda4
|-sda5 swap Swap 81c9827f-5952-4bb2-b1b2-298be789abee [SWAP]
|-sda6 ext4 7b839431-514c-44a7-a1d3-9baeffb595e0
`-sda7 ext4 f4d4b4d3-5869-492a-bf56-25a2970dc432
--- End code ---
MTCAT:
Hi Rich,
Thanks for the help, I was wrong, surprise, surprise :), there isn't a problem with the UUID in extlinux.conf for the new build "ROVER" receiver.
I plugged in the cloned TC boot pen drive (for the ROVER) in Lubuntu and typed "lsblk -f" and saw that the UUID for the cloned TC boot pen drive is the same UUID that's in the extlinux.conf, so that's good.
So then I also turned on my existing "BASE" station system, the fully functioning receiver, that boots properly and runs the acquisition program just fine, I checked on the UUID of the CF-card on the "BASE" receiver by typing "blkid /dev/sda5" and it's the same as the UUID of the new "ROVER" CF-card that I checked on in Lubuntu (the UUID for the boot pen drive is also the same on both systems).
So it seems like it's not a problem with UUID's, but does it seem strange that two different CF-cards in two different computers have the same UUID?, unless it's because both CF-cards were copied/created from the same Lubuntu image file?
Again, the 128 GB CF-card in the BASE receiver (the fully functioning one) and the CF-card in the new "ROVER" receiver (the one I'm trying to get going) have the same UUID.
In the "BASE" receiver the boot pen drive is mounted as sdb1 and the CF-card as sda5.
The only other thing I don't recall yet is how you helped me make a symbolic link on the CF-card so that acquisition data gets saved to home/tc/data, could that be hanging the boot up process? I need to check my piles of chicken scratches called notes how you helped me do that!
Thanks,
David
Rich:
Hi MTCAT
--- Quote from: Rich on Today at 04:33:23 PM ---UUIDs are unique for each device. ...
--- End quote ---
Assuming they were created by formatting, or
maybe it occurs when partitions get created, I
forget.
If you clone one device to another, the UUIDs
get cloned too. Using the dd command to copy
one device to another is an example of how that
could occur.
Navigation
[0] Message Index
[#] Next page
Go to full version