[Solved] TC3.8_4 Real Time Upgrade

[MTCAT]

Hi Rich,

I attached the output of lsmod for the "original" non RT kernel here, and dmesg as well.

Thanks,

David

[MTCAT]

Hi Rich,

Here's the output of lsmod and dmesg for the "home-made" or "built from scratch" RT kernel (this is the RT kernel where we had to run "sudo udevadm trigger" to get the OS to see the ethernet port).

Both the "original" non-RT kernel, and the "home-made" RT kernel are able to see an "ACPI" thermal zone0 which always reports 66 C.

Both the "original" non-RT kernel, and the "home-made" RT kernel have slightly different  ACPI behaviour (see lines 288 to 292 in their respective dmesg files) as compared to the "pre-built" RT kernel.

For some reason, the "pre-built" RT kernel doesn't show this ACPI behaviour, the "thermal zone" entries are missing from it's dmesg file (see latest_dmesg.txt), something must be different with how ACPI is configured perhaps ?

In any case, I'm  a bit suspicious of the 66 C reading when it is available anyway, I don't see any temperature readings at all in the DX3 BIOS, so....., I've queried WinSystems to see if this board (PPM-C412) has any onboard temperature sensors at all, hopefully they'll respond in the next few days.

I suppose if it doesn't have any temperature sensors, I could either add my own somehow ?, or simply comment out the "sensors" line in the acquisition code and feed the program dummy temperature readings, which would be a shame, as that's useful information to know, but would keep the program happy at least.

Thanks,

David

[Rich]

Hi MTCAT
The working kernels don't appear to be loading any modules related to temperature monitoring. It's possible some modules
built into the kernel are being used, but they wouldn't show up using lsmod.

You can see if any of these boot codes make any difference:

Code: [Select]

apm=on
apm=smp
acpi_pm_goodA list of boot codes valid for a 2.6.33 kernel can be found here if you're interested:
http://redsymbol.net/linux-kernel-boot-parameters/2.6.33/

Just a thought, but if temperature really is important, a better option would be to connect a sensor to one of your
A/D channels and get it that way.

[MTCAT]

Hi Rich,

Thanks for the ideas, I tried those boot codes but nothing worked, except sometimes the boot "dead-time" (the dead time when the DX3 sits there seemingly doing nothing after loading the 24DSI driver) seemed to be eliminated, or much reduced.

But, I'm not sure if the DX3 even has a built in temperature sensor, so until I hear otherwise from WinSystems, I may as well just return dummy values in Peter's subroutine for temperature, I did find out that lm_sensors won't work with the acpitz "digital" sensor, see the "Hardware Support" part, laptop discussion, in here

https://github.com/lm-sensors/lm-sensors

For now, I think I'll move on to getting chrony to save the necessary log files (position, date, time, etc) and hopefully get the acquisition code up and running at least.

Inside the attached program, lines 61 to 90, I think I could comment out all the lines except for lines 61, 90, and then change lines 87 and 88 to something like,
*cpu_temp=50.0;
*board_temp=50.0;

I think that would work ?, to simply return dummy values of 50.0 C from subroutine get_temperatures ?

Thanks,

David

[MTCAT]

Hi Rich,

Sorry, forgot line 68 would need to remain uncommented as well, so all lines commented except for 61,90,68 and then change lines 87, 88 to dummy values of 50.0 C.

Thanks,

David

[Rich]

Hi MTCAT
Paste this before the  get_temperatures  routine:

Code: [Select]

static int get_temperatures(double *cpu_temp, double *board_temp)
{
    /* Returns dummy temperature.
     */

    *cpu_temp = 50.0;
    *board_temp = 50.0;

    return (0);
}Rename the original routine to  get_temperatures_old. That should make it clear in the future if the code is examined
that there was/is an issue here.

[MTCAT]

Thanks Rich, I'll do that, that's a great idea to make a whole new subroutine, thanks again. I did find some little USB-stick temperature sensors that I could use (I think) if I want to down the road, could just attach the thermocouple to the CPU heat sink to get a ~ CPU temperature, better than nothing.

https://www.dracal.com/store/products/usbtenki/index.php

https://www.tindie.com/products/electromake/usb-thermometer-ds18b20-win-linux-pc-rpi-2/

I've got chrony saving log files now, so that's good, may have to put a "rm /home/tc/chrony/logs/statistics.log" or similar in a startup script though else the file size will get out of hand eventually, the log files just continue to grow for as long chrony runs, even across power up/power down cycles. I put the log files in home so the directory structure would be persistent but downside is I will need to wipe them out on every boot-up I think. I've had it up and running for maybe an hour or so, and the two log files (statistics.log, tracking.log) are about 20 kB each (if I recall correctly), not massive, but,could pile up eventually. Then just have to figure out Peter's little command he uses to pull out the clock offset, etc., from these files.

Then, last thing (hopefully) will be to make a little script "sudo cat /dev/ttyS0 > nmea.txt" and get Peter's program to pull the location (latitude/longitude) out of the .txt file, the "trick" will be, how long do I have to wait in general before I have valid GPS position, not sure, maybe I could just put the above command into the start_logger script so that as we start the logger, we also pump out some NMEA sentences ? When the device doesn't move more than a few hundred km, the GPS starts up quite fast (30 seconds or so ?), but when moved to a new position, it takes longer (several mintues, maybe even 5 minutes) as it has to search for the new satellite constellation first (I think).

This is fun doing all these tweaks to get the program to work, feels like it's near the end, then just have to re-do the whole process on 4 or 5 more, yikes !

Thanks,

David

[MTCAT]

Hi Rich,

While gpsd is running (collecting all the GPS info off ttyS0) I guess I can't run "sudo cat /dev/ttyS0" w/o messing up gpsd and therefore also chrony. Looks like I need to use a program called "gpspipe", I notice that this in the TC 3.x repository under "gpsd-clients.tcz", hopefully I won't mess anything up by already having "gpsd.tcz" installed....or, I could run "sudo cat /dev/ttyS0 > nmea.txt" before starting gpsd and chrony, that could work too...., as long as the GPS was "happy" at that point.

Thanks,

David

[Rich]

Hi MTCAT

... I did find some little USB-stick temperature sensors that I could use ...

The first thing I would do is run this command (Yes, the backslash in front of the underscore is intentional):

Code: [Select]

grep -r "get\_temperatures" Path/To/Sourcecode/*Then use the result to see what is actually being done with the temperature(s).

...  the log files just continue to grow for as long chrony runs, ...

The attached file shows a command to trim a text file to the last 100 (or whatever number you choose) lines.

... how long do I have to wait in general before I have valid GPS position, ...

This should tell you if chrony is synchronized to a satellite:

Code: [Select]

chrony sources | grep "\*"
The description for this is:

S
    This column indicates the state of the sources. "*" indicates the source to which chronyd is currently synchronized. "+" indicates acceptable sources which are combined with the selected source. "-" indicates acceptable sources which are excluded by the combining algorithm. "?" indicates sources to which connectivity has been lost or whose packets do not pass all tests. "x" indicates a clock which chronyd thinks is a falseticker ( its time is inconsistent with a majority of other sources). "~" indicates a source whose time appears to have too much variability. The "?" condition is also shown at start-up, until at least 3 samples have been gathered from it.

This should tell you how far off your clock is:

Code: [Select]

chrony tracking | grep "System time"
System time     : 0.000001501 seconds slow of NTP time
The description for this is:

System time
    In normal operation, chronyd never steps the system clock, because any jump in the timescale can have adverse consequences for certain application programs. Instead, any error in the system clock is corrected by slightly speeding up or slowing down the system clock until the error has been removed, and then returning to the system clock's normal speed. A consequence of this is that there will be a period when the system clock (as read by other programs using the gettimeofday() system call, or by the date command in the shell) will be different from chronyd's estimate of the current true time (which it reports to NTP clients when it is operating in server mode). The value reported on this line is the difference due to this effect.

Found here:
https://jfearn.fedorapeople.org/fdocs/en-US/Fedora_Draft_Documentation/0.1/html/System_Administrators_Guide/sect-Checking_if_chrony_is_synchronized.html

[MTCAT]

Hi Rich,

Thanks so much for all that info, and that little script, that could be very useful! I'll have lots of things to try this weekend, hopefully I can get the acquisition program fully up and running this weekend.

Thanks,

David

[MTCAT]

Hi Rich,

I made the new subroutine to return dummy temperature values (and re-named and commented out the original one). In the new subroutine, I don't need to declare "cpu_temp" and "board_temp" as double variables since that's done right in the subroutine definition line ?, right at the start ?, just wanted to make sure, that's definitely different than Fortran !, would find out in any case when compiling I suppose !

I'm trying to get the offset and error out of the chrony log file located in /home/tc/chrony/log/statistics.log, I thought I would try it this way first since this is how Peter does it (with ntp log files though).

If I execute "tail -2 /home/tc/chrony/log/statistics.log" we'll get what's shown in out.txt file attached here. I want the numbers in the second and third columns (of numbers), that's the offset and the error (std. deviation) respectively (I think I would want just the second row though, which is for the PPS source).

Executing "tail -1 /home/tc/chrony/log/statistics.log | cut -d ' ' -f 1" gives me the date, like "2021-07-11", so I think that's good.

And then executing "tail -1 /home/tc/chrony/log/statistics.log | cut -d ' ' -f 2" gives me the time, like "20:37:56", so I think that's good as well.

But, executing "tail -1 /home/tc/chrony/log/statistics.log | cut -d ' ' -f 18" works for the second column and executing "tail -1 /home/tc/chrony/log/statistics.log | cut -d ' ' -f 20" works for the third column, but only when all the numbers are positive, a negative sign in there will mess things up since I'm using the ' ' (a space) as the delimiter.

Is there a good way to get around that with a better use of the "cut" command ?

Otherwise, I would need to get the offset and error from the output of "chronyc sources" (like you suggested) but I think even there I would have the same issue when running something like, "chronyc sources grep PPS | cut -d ' ' -f 41" (for the offset) and then "chronyc sources grep PPS | cut -d ' ' -f 46" (for the error), but again, this isn't foolproof since the output of "chronyc sources" isn't always "fixed format".

Thanks,

David

[MTCAT]

Hi Rich,

Sorry, I should have referred to the variables as "*cpu_temp" and "*board_temp", not used to seeing that asterisk there, I guess this indicates a pointer to a memory location ? (from what I've been able to read), quite different than Fortran...!

Thanks,

David

[Rich]

Hi MTCAT

... (and re-named and commented out the original one). ...

No need to comment it out. By renaming it, the compiler won't generate any code for it because it's not referenced
anywhere else in the program.

... I don't need to declare "cpu_temp" and "board_temp" as double variables ...

Correct. The subroutine is being passed pointers to doubles. When manipulating pointers, this alters the pointer:

Code: [Select]

cpu_temp=This alters what the pointer is pointing to:

Code: [Select]

*cpu_temp=

... I'm trying to get the offset and error out of the chrony log ...

Don't do multiple tail commands to parse the same line. The file could get updated between 2 tail commands.
I've attached a file that shows what you want to do.
Line 1 assigns the result of the tail command to a variable.
Line 2 echos the contents of the variable. You'll note the whitespace has been reduced to 1 space between each field.
Lines 4 and 5 show the echo and cut command assigning the values you are looking for to  offset  and  error.
Line 6 echos the contents of  offset  and  error.


*** Pay close attention to backtics  `  vs apostrophes (single quotes)  '. ***

[MTCAT]

Hi Rich,

Thanks for the explanation regarding the pointers, that's something new I've now learned, thanks.

Thanks for the commands to do a nice job of parsing the chrony output file, I'll try that this weekend.

Then I just need to get the NMEA sentences from the GPS, either before gpsd starts up and "hogs" ttyS0, or with "gpspipe" (to communicate properly with gpsd). I've already installed the gpsd package (gpsd.tcz) from the TC3.x repository but in order to get "gpspipe" it looks like I need to install "gpsd-clients.tcz", hopefully that will be okay to install gpsd-clients.tcz with gpsd.tcz already installed.

Thanks,

David

[Rich]

Hi MTCAT

Thanks for the explanation regarding the pointers, that's something new I've now learned, thanks. ...

Fair warning, there's more to pointers than what I described.
This declares a pointer to a double:

Code: [Select]

double *cpu_temp;
This declares 2 doubles, then a pointer to a double and initializes the pointer to celcius. What it ls pointing
to (celcius) is unaffected:

Code: [Select]

double board_temp;
double celcius;
double *cpu_temp=&celcius;
get_temperatures expects 2 pointers to doubles. The first variable is a pointer. The second variable is
the address of a double, which is the same thing a pointer would pass to the subroutine.

Code: [Select]

get_temperatures(cpu_temp, &board_temp);