[Solved] TC3.8_4 Real Time Upgrade

[MTCAT]

Hi Rich,

Referring to the attached program, line 117, would it work if I replaced line 117 with a "call" to a script file, lets say it's called "parse_chrony.sh" containing the commands in parse.txt you attached previously (except maybe for lines 2 and 6, the echo to screen commands).

char *cmd="/home/tc/parse_chrony.sh"

As I understand it, popen puts the output of the command in the string into a file called "in" in my case (due to using the "r" option), and then down below (line 122), Peter uses fgets to put the contents of  the file "in" into a character variable called "buf" I think, and then uses "sscanf" (line 131) to read the offset and the jitter as doubles out of "buf" (I don't why the !=2 is in the sscanf line though, something not equal to 2), and then outputting the offset and jitter in milli-seconds (if it's less than 0.25 seconds dt=dt*1000), or, outputting 1000.0 (milli-seconds) if the offset or jitter is > 0.25.

It would seem much easier to just use your nice commands to save the offset and error values into a file, and then just load that file, and return those values ?

Thanks,

David


I think that's what's going on there in subroutine get_pps_offset ?

[Rich]

Hi MTCAT

Referring to the attached program, line 117, would it work if I replaced line 117 with a "call" to a script file, lets say it's called "parse_chrony.sh" containing the commands in parse.txt you attached previously (except maybe for lines 2 and 6, the echo to screen commands).

char *cmd="/home/tc/parse_chrony.sh" ...

Yes, that should work, but you want the second echo command to echo the 2 variables being read from  peerstats
by  get_pps_offset. You should not need to change anything else to make it work.

... uses "sscanf" (line 131) to read the offset and the jitter as doubles out of "buf" ...

And that's precisely what should be in  buf , no more, no less.

... I don't why the !=2 is in the sscanf line though ...

sscanf  returns the number of items successfully matched and assigned. If 2 items are not processed, then -1 is
returned indicating an error.

[MTCAT]

Hi Rich,

Oh, okay, thanks, I'll keep that second echo command in there then, unfortunately I didn't get a chance to do anything this past weekend, hopefully will try this tomorrow or Wednesday at latest. Then I just have to get gpspipe going to retrieve NMEA sentences, I think "gpspipe -d -o nmea.txt" would work to output NMEA sentences into a text file "nmea.txt", and then just need another little script file to read out the lat-long and number of satellites out of "nmea.txt", and hopefully that will be it !, hopefully Peter's program will be 100 percent happy at that point !

Thanks,

David

[MTCAT]

Hi Rich,

I put your nice commands into a script file called "parse_chrony.sh" and looks great, thanks a lot. I downloaded gspd-clients.tcz to get the "gpspipe" utility which is able to retrieve NMEA sentences from gpsd, I ran  "gpspipe -r -n 100 > nmea.txt" and attached the file here. Would you happen to know of a good way (in terms of bash commands) to extract only the $GNGGA sentence(s?) in the attached text file ? If you can show me how to get only the $GNGGA sentences into a new file (which I'm sure you can !), maybe called "gngga.txt" ?, Peter's command (line 195 in gps_ublox.c) should do the trick I think, in my case it would be "tail -1 /home/tc/chrony/log/gngga.txt | cut -d ',' -f 3,4,5,6,7,8"

Thanks,

David

[Rich]

Hi MTCAT
The following will create a new  gngga.txt  file every time you run it:

Code: [Select]

grep '$GNGGA' nmea.txt > /home/tc/chrony/log/gngga.txt
This will create a new  gngga.txt  file the first time it is run, and append to the existing  gngga.txt  thereafter:

Code: [Select]

grep '$GNGGA' nmea.txt >> /home/tc/chrony/log/gngga.txt
Note the single quotes used so that  grep  looks for a literal dollar sign.

[MTCAT]

Hi Rich,

You're amazing, thanks a lot Rich.

Thanks,

David

[MTCAT]

Hi Rich,

I got script files setup to extract the offset and error from /home/tc/chrony/log/statistics.log (parse_chrony.sh), and another one to extract the GNGGA sentence from /home/tc/chrony/log/nmea.txt (parse_nmea.sh), I then modified "gps_ublox.c" to call these script files to get the required information, okay, cool. Unfortunately when compiling though, I'm getting an error related to the new "get_temperatures" subroutine which "dummies" out the temperature to 50.0, I attached the output from stderror here, and the modified gps_ublox.c routine as well. Did I do the comments wrong on the original get_temperatures subroutine ?

Thanks,

David

[Rich]

Hi MTCAT
This marks the beginning of a comment  /*
This marks the end of a comment  */
You don't need additional asterisks on each line.
You also can not comment out a comment, i.e  /* some C code /* A comment */ */

I'm going to make the same recommendation I made previously, don't comment out the original code. Just rename
the original routine, which you did. Remove your attempt at commenting it out.

gps_ublox.c: In function 'get_temperatures':
gps_ublox.c:67: error: invalid operands to binary * (have 'double' and 'double *')
gps_ublox.c:69: error: expected ';' before 'return'
gps_ublox.c:70: warning: no return statement in function returning non-void

You omitted the semicolons that mark the end of a statement. Look at what I wrote again:
http://forum.tinycorelinux.net/index.php/topic,24944.msg160104.html#msg160104
Then compare that to what you wrote.

[MTCAT]

Hi Rich,

Thanks for the quick reply, I'll undo my commenting out attempt of the "get_temperatures_original" subroutine and add those semi-colons in the "get_temperatures" subroutine, sorry I missed that.

Thanks for the info re: commenting in C, interesting.

Thanks,

David

[MTCAT]

Hi Rich,

Thanks again, that worked, mt_logger fully compiled now with no problems. But, when I tried to start the acquisition program (./start_logger_TC.sh), the GUI is still frozen, the normal acquisition GUI screen comes up, but then all of the buttons and tabs within the acquisition window are still non-responsive (frozen), not sure where to start on that in terms of troubleshooting. When I minimize the acquisition window, and then bring it back up, it comes back just as a blank off-white screen with "MT Logger" in the upper left corner, maybe that's a hint ?, maybe an issue with this glade library or something ?

Thanks,

David

[MTCAT]

Hi Rich,

Sorry for all the posts, I did actually find an error in "mt_adc.log", see line 60 attached here, some kind of issue with the A-D driver it seems ? I'll contact GSC as well regarding this error, the GSC test programs have always run okay, so I'm not sure why we would be having an issue now.

Thanks,

David

[Rich]

Hi MTCAT
Sorry, I can't tell you anything based on that log.

[MTCAT]

Hi Rich,

I re-ran the "./rxrate", "./id" and "./billion" test programs for the 3.17.52 driver and they all work fine, but, I do notice that the GSC test programs just report "(DMA)" for their communication, if that's the right word. But, for some reason, in Peter's program, it's "DMDMA" (Demand-Mode DMA) that's being attempted to be used. I'm tempted to uncomment the line in adc_control.c that's specifies "regular" DMA and then comment out the "DMDMA" line immediately below it, just to see if that works.

But, bigger picture, that makes me concerned again that I'm still not working from the same source-code that produced the working executables on my two functioning receivers, maybe there's no way to truly tell the correct version other than trial and error ?

Still waiting to hear back from GSC.

Thanks,

David

[MTCAT]

Hi Rich,

No difference when using the other DMA mode (adc_control.c), I did find in the main program (mt_adc.c), attached here, that there is some extra debugging info, lines 146/147 were commented before, I uncommented them and re-ran and got a bit of extra information shown in the attached log file, not sure how this is supposed to help though.

I also re-tried running the program with lower sample rates of 100,000 samples/sec and even 10,000 samples/sec, still got the same error.

Still waiting to hear from GSC.

Thanks,

David

[MTCAT]

Hi Rich,

I found out that the "error" I'm seeing in "mt_adc.log" is actually to be expected, it seems to be a consequence of shutting down mt_adc when clicking on the 'x' on the terminal window in which it's running. I actually see this same "error" in the log file on my properly functioning receiver, sigh. I think mt_adc runs continuously and when it's abruptly turned off by closing the terminal, complains a bit.

I did find one problem, maybe, Peter has the data directory defined in "setup.c" (for mt_logger) simply "home/data" (yet it's reported in the mt_logger,conf file as /home/emp/data, which is for my Slackware boxes), I forgot to change this to "/home/tc/data" in setup.c, I did this, but to no effect, and in fact, it doesn't seem that the mt_logger.conf file is being written out at all, maybe because the program is not fully up and running yet.

So I don't know, maybe it is a graphics (glade ?) issue, the GUI is basically frozen, although I did get it to switch over to the "Channels" tab one time, not sure how that happened, but the GUI did respond kind of, once anyway. There's a strange script file (attached here), looks pretty odd to me, maybe glade is not getting setup properly somehow for the new display situation (VDX3, 15 inch VGA monitor, as opposed to the old situation, which is a small 7 inch (?) LCD display), I could just hook up one of the LCD screens to see if it's still using the "old" settings or something ?

But, I'll be gone til the end of next week, so, will have to wait I guess.

Thanks,

David