[Solved] TC3.8_4 Real Time Upgrade

[MTCAT]

Hi Rich,

As usual, egg on my face, I thought I figured out how Peter was making the tables but was totally wrong, I found another directory called "mt_timing" with some more programs in it, attached them both here, it looks like he generates a bunch of data (log) files with PPS timing info in them which then get loaded and analyzed to make the tables, but, I don't think I have the program that does the actual analysis (??), but maybe some insight there for us regarding the table generation. There's a bunch more data files, etc., in the "mt_timing" directory but size limits won't let me post it all. Unfortunately, Peter uses the same name (pps_stats.c) for two programs that are very different, he did the same thing with shared_mem.c, makes things a bit confusing, at least for me.

Thanks,

David

[Rich]

Hi MTCAT

... Down the road, I wonder if we could improve the zero-cross location by doing a super-fast sampling of the PPS waveform ...

It's not a zero crossing, it's a threshold crossing. And it's not a hardware threshold, it's a software threshold. That means
the threshold is basically whatever you say it is. In pps_stats.c Pete defines it as:

Code: [Select]

(Vhi-Vlo)/2but there's nothing that says it can't be:

Code: [Select]

(Vhi-Vlo) * 6/10or:

Code: [Select]

(Vhi-Vlo) * 4/10

[MTCAT]

Hi Rich,

Thanks for the help, just getting going on this today,  for me,

cat /proc/sys/kernel/shmmax
33554432

Divide that by 1024 and we get 32,768. So I need to increase this to 256 MBytes, I did a "sudo find -name sysctl.conf" but nothing came up. I also tried "sudo echo 268435456 > /proc/sys/kernel/shmmax" but I got an error;

sh: can't create /proc/sys/kernel/shmmax: Permission denied

One other command I had written down, which I didn't try was, "sysctl -w kernel.shmmax=<value", maybe this is the correct way to do it ?

Thanks,

David

[patrikg]

When piping with sudo i don't think it work.
You have to use something like this.

Code: (bash) [Select]

sudo sh -c 'echo 268435456 > /proc/sys/kernel/shmmax'

[Rich]

Hi MTCAT
Try it like this:

Code: [Select]

echo 268435456 | sudo tee /proc/sys/kernel/shmmax

[Rich]

Hi MTCAT

... One other command I had written down, which I didn't try was, "sysctl -w kernel.shmmax=<value",  ...

Yes, you could also do this:

Code: [Select]

sudo sysctl -w kernel.shmmax=268435456
Or you can do it like patrikg suggested. Lots of ways to get the same result in Linux.

[MTCAT]

Hi Rich and partikg,

Thanks a lot, I will try one (or more ) of those commands, I will test as well if this needs to be done on every boot-up, if so, I can just make a little script and then call it out of bootlocal.sh

One other complication, right now my CF-card (sda5) has Lubuntu (16.??) on it, so when I mounted it, and tried to "mkdir /mnt/sda5/data", I was denied permission as all the directories and file on sda5 appear to be "root" ownership. I could either wipe Lubuntu off the CF-card completely (by reformatting ?) or just "sudo mkdir /mnt/sda5/data" followed by "chown tc /mnt/sda5/data", I think that would be okay ? I assume I'll be running the acquisition program as a regular "tc" user.

Thanks,

David

[Rich]

Hi MTCAT

Code: [Select]

sudo mkdir /mnt/sda5/data
sudo chown tc:staff /mnt/sda5/data

[MTCAT]

Hi Rich,

I added a couple more script calls to boolocal.sh, one to increase shmmax to 256 MBytes, and another to mount sda5, so that's cool, working automatically now at boot up, forgot again that I had to make the scripts executable (chmod 775 .....)

I also got all the config files off one of my existing receivers and found the startup-script linked to the desktop icon, attached it here.

It looks like the code on my existing (working receiver) is a bit different from the mt_logger and mt_adc code I previously compiled on the DX3, which I got from a "'home/pete/backup" directory (maybe was an old b/u) but I think I'll just keep taking "baby-steps" and proceed with playing around with the acquisition code that's on the DX3 (from the old b/u), what do you think ?

I only briefly looked at the "current" code from my existing receiver but I see some differences there with NTP (which I'm not using actually), and some other things.

Thanks,

David

[Rich]

Hi MTCAT
I think the attached file would be the equivalent under Tinycore. You might have to change  aterm  to  xterm.

[MTCAT]

Hi Rich,

Thanks for the modified script file, I modified the "hard-coded" path's to the config files in the C-code, re-compiled, and changed the path in the script to "/home/tc/.local/bin/..." and I think it worked except now I'm getting a "pipes" communication error, can't open pipes. I did notice a "#define" statement like #define INPIPE "/tmp/mtin" and also #define OUTPIPE "/tmp/mtout" inside "mt_adc.c"

I do have a /tmp directory but,..., still didn't work.

But I could swear that I read in the code that I'm playing around with that Peter abandoned "pipe" communication for the shared memory segment "thing", so I'm a bit confused (as usual).

So, hmm, not sure, perhaps I should just "bite the bullet" and try to get the most current version of the code going, or at least what I think is the most current version, which is the version that's running on my two existing receivers, I guess I have to do that at some point anyway....what do you think ?

Thanks,

David

[MTCAT]

Hi Rich,

One mystery solved, I had two .tgz files in the same backup directory as a bunch of uncompressed code, I assumed that the uncompressed code came out of the .tgz files, I was wrong, the code in the .tgz files (which I expanded on the VortexDX3) is different than the uncompressed code in the backup directory, the source code in the .tgz files must be older, still using pipe communication, while the uncompressed code uses the shared memory technique. When I originally studied the source code I did so with the uncompressed code (hence the abandoning pipes for shared memory comment), so that was my mistake there.

I then also have a third version of the acquisition code which is directly out of the run directory of my existing working receiver. I guess I should just try to move forward with that.

Thanks,

David

[Rich]

Hi MTCAT
You should try to figure out which one is the current working version. Presumably the latest one? Maybe see if there
are revision levels or version numbers listed somewhere. You can see which  .tgz  file is newer by checking the timestamps
of the contents:

Code: [Select]

tar tvf FILENAME.tgzChecking the timestamps of the  .tgz  files won't work because those get changed every time you copy them unless you
use the  -p  switch when copying.

[MTCAT]

Hi Rich,

Mark it on the calendar !, June 27/2021,  with all your help, I got the GUI for the acquisition code to come up ! ! !, , this is awesome !, thanks so much for all your help, and Juanito, curaga, bmarkus, patrikg and PDP-8 too (hope I didn't forget anyone)!!!

I used what I think is the newest version, compiled that, and voila ! There is something weird though with Peter's Makefile, I don't think the "make clean" command is working properly to remove the old install, even though I compiled and installed the new version, after running the startup script I initially was still seeing the "pipe error" as if the start script was running the old (and identically named) compiled version, so I just removed the old install manually from ~/.local/bin, and then re did "make" and "make install" and off we go.

Only thing left to do now (I think) is the good old GPS, Peter uses NTP to save a "peerstats" file and a "clockstats" file (in /etc/ntp/stats I think) and then reads a bunch of information out of that, so I just have to figure out how to get chrony to do that to keep Peter's program happy.

Oh, also, Peter has a "sensors" command as well, it almost looks like a DOS batch file command or something in the C code, something like "cmd * = sensors...." or something like that, he uses that (with tail) to get the CPU and board temperature. So need to get that as well.

Because those items are missing (hopefully that's the only reason), the GUI is hung up, none of the tabs or buttons work, but I was really happy to see all the graphics come up anyway..

So I think that might be it, hopefully that won't be too difficult to get going, but otherwise, the program seemed to interrogate the A-D properly, and load all the config files, etc., so just a few small details to go I think.

Very exciting, thanks again for all the help.

The new version of the program also appears to have the ability to do statistics on the PPS, by doing a 12 hr recording of the PPS, and then generates the "CDF" tables as well, so that could be handy. But it's just stated in a comment line that you have to use the "- pps switch" to do the statistics collection, but there's no documentation other than that.

Thanks,

David

[Rich]

Hi MTCAT

... Oh, also, Peter has a "sensors" command as well, it almost looks like a DOS batch file command or something in the C code, something like "cmd * = sensors...." or something like that, he uses that (with tail) to get the CPU and board temperature. So need to get that as well. ...

I've already made the syntax, spelling, punctuation, capitalization speech several times. I can't work with vagaries.