heres the scenario-
I have 2 pi-4B's, both have different duplex hats, different nextion screens
whats pissing me off is the info on the screens. At some point, someone on this forum said to change the file Stripped.csv to be users.csv
been that for a month or more. On SOME peoples transmissions, it tells their info then CHANGES to "NOT FOUND IN USERS.CSV
yes, I said it CHANGEs after showing the correct info.
so, I say WTF?
Chris aka KB2IDX
Duplex-Nextion-data read outs
Re: Duplex-Nextion-data read outs
Support for Nextion screens was a late add-on to Pi-Star and as such has never been fully integrated into all the platform's daily procedures and tasks.
First off, the stripped.csv (or users.csv) file is not updated on any schedule, so it remains perpetually out-of-date and requires manual updating.
Secondly, the Nextion Driver is not cycled daily like other tasks: the users file is loaded just once, at startup, and therefore would normally not see any updates to the underlying list unless it were cycled/rebooted.
Both of these issues are solvable, have been solved by some, but even then, some callsigns will continue to show up as "not found" simply because of the timing of the above processes and because, in some rare situations, there appears to be some non-standard callsigns (with extraneous characters appended) in the streams that hinder lookups or parsing.
It is what it is; chances are that the "not found" is fleeting and quickly forgotten when the next QSO starts - no need to obsess about it.
First off, the stripped.csv (or users.csv) file is not updated on any schedule, so it remains perpetually out-of-date and requires manual updating.
Secondly, the Nextion Driver is not cycled daily like other tasks: the users file is loaded just once, at startup, and therefore would normally not see any updates to the underlying list unless it were cycled/rebooted.
Both of these issues are solvable, have been solved by some, but even then, some callsigns will continue to show up as "not found" simply because of the timing of the above processes and because, in some rare situations, there appears to be some non-standard callsigns (with extraneous characters appended) in the streams that hinder lookups or parsing.
It is what it is; chances are that the "not found" is fleeting and quickly forgotten when the next QSO starts - no need to obsess about it.