Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
What is it with CG3EXP
|
Jan,
toggle quoted message
Show quoted text
My decodes seemed to be stuck at the same location also. I went to the C3 homepage and found info on the trip schedule. They seem to be stopping at different places along the way, sometimes for multiple days. 73 de N8OOU - Mike Meek On 06/04/2017 05:24 AM, Jan Olof Bergst¨¦n wrote:
The transmitted locator seems faulty. Today it is jumping between FN14ka and FN14sf. Yesterday it showed mainly FN14ka. |
||||||||||||||||||||||||
|
Hi all Yes, the C3 ship is not travelling continuously. It is stationary sometimes for a day or two in one port. Sailors gotta eat, drink, be merry etc. That doesn't explain the strange locator action.? I have a PARTIAL theory.? The U3S and the QLG1 GPS are NOT at fault. I think what we are seeing here is a feature of the way WSPRnet handles the "extended WSPR" mode which sends 6-character locators and/or callsign pre/suffixes. In extended mode the two WSPR transmissions are sent. They are linked together by a 15-bit hash-code which tells each receiving station's PC which callsign the second transmission part belongs to. A station receiving both parts can report the full 6-char locator.? I don't know exactly how WSPRnet or the WSPR decoding programs are handling the situation and perhaps even different WSPR decoders handle it differently. But studying the WSPRnet data? you can see a clear pattern. Firstly understand the transmission schedule. The frame is 20 minutes. Starting on the hour: :00 and :02 are the 20m transmissions? :04 and :06 are the 30m transmissions? :08 and :10 are the 40m transmissions? Then an 8 minute pause until the end of the 20 minute cycle, during which GPS calibration is done. On each band there are two WSPR transmissions because extended WSPR (6-char locator) is enabled. What you can see is that the second part reports, on minutes :02 and :06 and :10 always show the correct locator FN14sf. The first part reports :00 and :04 and :08 show locators where the 5th and 6th characters are sometimes incorrect. Even a station such as K9AN who is reporting every single spot on every band without fail, has an incorrect 6-char locator in the 1st transmission of each pair. And different stations report various different 6-char locators for the 1st transmission. Categorically this MUST be a bug in the decoding software in one or more of the WSPR decoding packages. It CANNOT be an issue with the U3S transmitter since it cannot possibly transit multiple locators all at the same time in one WSPR transmission slot! The first transmission contains only the 4-char locator FN14 and the 5th/6th in the WSPRnet database are being artificially added (incorrectly) by either the WSPRnet site post spots upload, or by the WSPR decoding software pre-upload. Remaining mysteries include why the 5th 6th characters are a few values only; where they are generated from; and why this only seems to show up when the ship has been stationary for a while, not when it is moving. From my side the workaround is quite simple. I can easily manually remove the spurious coordinates on the Google map path. Then I will modify the tracking software and cause it to ignore the reports in the 1st of each pair of WSPR transmissions on each band. I should be able to sort that out either today or by tomorrow morning. The data in the WSPRnet database will still be wrong and I don't think the chances of getting that bug fixed there are particularly high ;-) ? But at least they won't show on the tracking map! 73 Hans G0UPL? ? On Jun 4, 2017 17:06, "Mike" <n8oou@...> wrote: Jan, |
||||||||||||||||||||||||
|
Jan, Hans,
toggle quoted message
Show quoted text
When I learned that they were going to be stopped in Kingston for a couple days, I stopped monitoring. I started wspr back up a few minutes ago and am capturing jumping positions, same as you. As I was typing this, a message from Hans was posted with his thoughts. I can add this small spec of info for you Hans, is that I am running wsjt-x here v1.7.0 in the wspr mode on 30m. Receive only. 73 de N8OOU - Mike Meek On 06/04/2017 09:47 AM, SM7ETW Jan wrote:
Yes, but if you zoom in on the tracking map there is a track up river. The position they are sending now is the one they originally departed from. Also the jumping locator is odd, a boat can not travel that fast. |
||||||||||||||||||||||||
|
Good day Hans,
toggle quoted message
Show quoted text
I have been watching CG3EXP's spots with respect to their sometimes wandering nature with their grid squares. Thanks to your description I better understand the transmission sequence but I am at a loss as to the understanding of how the six digit grid is firstly encoded and then decoded. I do understand the dependency of requiring both the first and sequence on the same frequency in order to fully decode the six digits. My observations are that it seems the grid squares remain stable when the ship is docked, for example now (2017-06-07 14:00 UTC) in Brockville where the ship has been docked since yesterday evening - grid FN24do. It only seems that the grid squares wander whenever the ship is actually in motion. when in motion we have to assume a few things: 1) the ship will travel between about near zero and up to about 14 knots and when maneuvering around the islands of the St Lawrence rive likely between 5 and 10. In other words, speed will vary 2) the path of the ship will not be linear. That is constantly West to East. As it maneuvers around the various Islands doing it's research (etc) it will move West to East, back again, as well as North to South and South to North. In other words expect it to maneuver in any direction at any time. It appears to me that when the ship is on the move around the islands (etc) that is when the grid squares are exhibiting the changing behaviour. As the ship moves and the GPS updates it's position the ship may cross over a border of one six digit grid to another and then back again all within a short period of time. As an example (using K9AN spots) I noted a movement from (sub grid) wh to wg to vg to vf to wf. These sub grids are all side by side and when plotted shows a movement fro wh south to wg then west to vg then south to vf the east to wf where the ship was possibly following a north to south on or near or crossing the boundary between v and w. As you have noted, the six digit grid square can be different from the first reported wspr spot to the second (i.e. two subsequent frames, two minutes apart for the same frequency as reported by the same station - and others). I am thinking that there may be some way to use this behaviour to derive in between positions, that is to half the explicit 5 minute by 2.5 minute precision of the six digit grid squares. In the U3 software when configured for sending six digit grids, does it use one static position (i.e. lat/long gridsquare) when the first two minute frame starts and for the second frame or is there a possibility that it may be updating between the two frames? Something of note, WSPR and WSJT-X permits the user to frequency hop. When I have this set up the software (using hamlib) while cause my receiver to change frequency every two minutes precluding or at least I think it would, decoding of these six digit grid squares, I think. I have been looking for some detailed information on how WSPR or WSJT-X does the encoding and decoding but I haven't been able to do a good job of sorting the chaff to get to the details. Can you point me in the right direction for some docuement(s) on those details, please and thank you. cheers, Graham ve3gtc On 6/4/2017, "Hans Summers" <hans.summers@...> wrote:
Hi all |
||||||||||||||||||||||||
I have been watching CG3EXP's spots with respect to their sometimesGraham Looking at the last 1000 spots when it has obviously been moving 998 of them are in the expected sequence, one or both of the last letters changing by one character. Two stations reported FN14sf out of sequence at 03.40 but maybe we can ignore that. But it was stationary when, for example, FN14sf to FN14vg in 22 minutes was reported. But since 21.22 yesterday UT FN24do has been reported by all... Just the two odd ones in a thousand, moving or not. I think Hans is right, some strange bug in one or more versions of WSPR, maybe something like a false decode? Perhaps you need to look at more than just one station to see the effects of different decoders? Or is it possible some GPS QRM? I'm not sure if it still happens but I think there have been a number of jamming tests in the past. Or radar etc? And where is the GPS antenna? 73 Alan G4ZFQ My observations are that it seems the grid squares remain stable when the |
||||||||||||||||||||||||
|
Indeed, this needs much more analysis.
the ship is on the move again, left Brockville around 16:40 UTC and now headed a little further downstream to Prescott Grids have been changing from do to eo and now ep. Consider this pair of wspr spots: 2017-06-07 17:02 CG3EXP 14.097116 -25 -2 FN24ep 0.2 K4RCG FM08si 2017-06-07 17:00 CG3EXP 14.097116 -16 -2 FN24eo 0.2 K4RCG FM08si both from the same receiving site and for the same 2x wspr sequence (i.e. two sequential transmissions) in order to encode/decode the six digit grid. Notice at hh:00 the grid was ep and hh:02 is eo. This makes sense with respect to the route the ship is travelling, Prescott is NE down the rive from Brockville. Same pattern earlier when the ship started to move out of Brockville: 2017-06-07 16:42 CG3EXP 14.097108 -18 -2 FN24eo 0.2 K9AN EN50wc 2017-06-07 16:40 CG3EXP 14.097110 -16 -3 FN24do 0.2 K9AN EN50wc do at hh:42 then eo at hh:42 this time Eastward but still continuing the general NE path to the next destination. I don't know enough about the software on the U3 nor the encode/decode process (but I am slowly figuring it out) but these two noted changes at least make sense with respect to the movement of ship and that it seems as though something changed between the first and second transmission and the respective spots are being reported correctly. things that make you go hmmm..... cheers, Graham ve3gtc On 6/7/2017, "Alan via Groups.Io" <alan4alan@...> wrote: I have been watching CG3EXP's spots with respect to their sometimesGraham |
||||||||||||||||||||||||
Indeed, this needs much more analysis.Graham, Yes, more than I'm capable of. This was a silly comment made just before I rushed off to lunch. Hans has already discounted the U3 and I think the problem is...Or is it possible some GPS QRM? I'm not sure if it still happens but I I also said "Two stations reported FN14sf out of sequence at 03.40" but I left the search page open and now I see those were at 04.20. But they were the only two spots for 04.20. This was 20m. The last 1000 on 30m shows no discrepancy. And i do not see any for 40m. Alan G4ZFQ |
||||||||||||||||||||||||
|
Hi Graham, Alan,? I can tell you some stuff about the U3S which will hopefully make it clearer, and will also show why I believe WSPRnet or WSPR decoding programs have a bug. I know this information is not published anywhere. I really can't recall how I discovered it but I do remember it took a lot of digging. Most likely I poked my head inside the PC WSPR software source code and reverse engineered the rules from that.? Firstly: The Ultimate3S reads the GPS NMEA serial data stream once per entire transmission cycle. It happens right before the calibration. In the case of CG3EXP, the U3S sends 12 minutes of WSPR (6 x 2-minute transmissions, i.e. a pair of WSPR transmissions on each band 40, 30 and 20m). Then it does a calibrate. The GPS position snapshot is therefore taken at approx 12, 42 and 52 minutes past the hour. One snapshot every 20 minutes. The GPS position is NOT updated for every 2-minute WSPR transmission. We have also seen many examples in the data over the last few days, where the position was reported differently by different stations, in the SAME 2-minute time slot.? Both of these facts individually, exclude any possibility of any GPS QRM, corruption, jamming etc. It is impossible to explain the observations by assuming faulty positions from the GPS.? Now to explain about how "Extended mode" WSPR works, in the case where you wish to send a 6-character Locator (with a normal callsign, such as CG3EXP).? A reminder first that an ordinary WSPR message consists of a callsign, 4-character locator, and power level in dBm. The power level is from 0 to 60dBm and only 0, 3, 7, 10, 13, 17 etc are allowed. These three fields (callsign, 4-char locator and power) are packed into 50 binary bits of data; then K1JT's clever stuff encodes that into 162 tones, each tone one of 4 frequencies separated by 1.46Hz. The clever stuff shuffles everything up and adds redundancy and forward error correction such that even in the presence of QRM or QSB etc we have the astonishing global HF performance of this mode even with very low powers. When sending the 6-character locator, the first WSPR transmission is a completely ordinary one. It sends as usual, callsign, 4-character locator, and Power level.? The second transmission sends 6-character locator, a 15-bit hash code, and the power. The packing into 50 bits is slightly different so that the WSPR decoder can identify this as the special 2nd kind of transmission. The 6-character Locator is simply placed in what would normally be the callsign field instead of the callsign. But it is rotated by one character. So for example, IO91AB is sent as O91ABI. This is so that the "rules" for WSPR callsigns (that govern the packing into 50-bits) are upheld. The 15-bit hash code is placed into what would normally be the 4-character Locator field.? The hash code is required because the 2nd WSPR transmission does not contain the callsign. Only the 6-char Locator, 15-bit hash code, and power. The 15 bits aren't enough to contain the callsign. Therefore the use of this hash code.? So what is a 15-bit hash code? A mathematical process converts a callsign into this 15-bit hash code. 15 bits means there are 32,768 possible values. Of course there are many more possible callsigns, than 32,768. Therefore this is a non-reversible computation, in which multiple callsigns map to each hash code value. It is non-reversible because when you have decoded the hashcode value, there is no way to know which of the many possible callsigns which map to that value, to use.? Therefore the WSPR decoder program at every receiving station, receives the first ordinary WSPR transmission and creates a table in memory of the callsigns and hash code pairs. Then when this station receives a Type 2 special transmission, it decodes the hash code and looks in its table, to find what callsign *probably* sent it (but not definitely). Stations could "clash" by having the same hash code. But in practice most people thankfully do not send 6-character "extended" WSPR so the probability of such a collision is very low.? The Ultimate3S implements the WSPR protocol faithfully, as it must, so that it matches the receiving station's decoding software. The above rules and limitations are all pre-existing before the U3S. And hurt my head a lot, writing all the code to handle.? So what it comes down to is this: The 1st of each pair of transmissions sends callsign, 4-char locator, power.? Example: ? ?CG3EXP FN24 23 The 2nd of each pair of transmissions sends 6-char locator, hash code, power Example: ? ?FN24fq <hash> 23 ? ?(I do not know what the hash code for CG3EXP is and it isn't important enough right now for me to work it out) A receiving station which has already received one of the first type of transmission, will have the callsign/hash code in its table in memory; and when it encounters the 2nd type of message, it will know which callsign probably sent it.? In a case where a station receives the 2nd type of transmission and has not received the first, I believe that this spot is discarded, not uploaded to WSPRnet - it cannot be uploaded because the WSPR decoder does not know what callsign to send to WSPRnet. Now you see - the first transmission of the pair ONLY sends 4-character locator. BUT, WSPRnet always shows a 6-character locator! Where does it get that 5th and 6th character from? This is the mystery! It makes them up, or guesses them, from somewhere! It MUST be guessing the 5th and 6th characters because the protocol is NOT sending them in the actual transmission. In all the data, we see the 5th and 6th characters flapping around sometimes. Most of the time the situation is well-behaved but occasionally a situation somehow arises where the 5th and 6th character "guesses" of the 1st WSPR transmission recorded in WSPRnet, jump between several possibilities. We saw cases where the same timeslot had several different values. The SECOND of the pair in WSPRnet always has the correct 6-character locator, which it must, because the whole 6-character locator is being sent in the WSPR protocol.? This is a paste of the WSPRnet log for the transition from FN24ep to FN24fq:
The interesting thing here is that at 17:20 the Ultimate3S has already taken a fresh snapshot from the GPS (actually taken at about 17:12 when the previous 6 transmissions cycle completed). The Ultimate3S knows that it is now at FN24fq. But at 17:20 the Ultimate3S is sending the 1st of the pair. Which only contains the 4-character locator FN24. Either WSPRnet, or the WSPR decoding programs, are "guessing" the 5th/6th characters are "ep"... so FN24ep is what is in the database. The 17:22 transmission is the 2nd of the pair and it shows the correct actual 6-character locator FN24fq.? Here the "guess" is quite reasonable because WSPRnet is just remembering the last 5th/6th characters it had for this callsign. What we don't understand is why occasionally, as on Sunday, everything goes crazy and the "guess" oscillates between several different values.? WSPRnet certainly stores its "guesses" in the database, per callsign - please refer to App Note AN002 "My QTH is many km wrong in the WSPR map ¨C how to fix it!", which is a tutorial on how to force WSPRnet to report your correct 6-character locator even though you are sending ordinary WSPR messages which only have 4-characters.? On the other hand, a strange thing that was noticeable the other day, was that C3 visited two ports, quite close together. For many hours the locators in the 1st reported WSPR message pairs were jumping around. But not randomly! On the map it looked like the subsquares were all close to a diagonal line across the Maidenhead square. That is probably an incorrect inference though. The diagonal also happened to follow the path of the water between these two ports. This is what makes me suspect that the "guess" may also be made by the WSPR decoding software at each monitoring station, as well as the WSPRnet database. I surmise that a particular WSPR receiving station may have received C3 (full 6-character locator 2nd message) as it was at a particular point in the short journey between these two ports. Some time later, when C3 was already at its destination, this same particular WSPR receiving station received the 1st message, and "guessed" the 5th/6th characters, setting them to what it had received some time earlier, and uploaded that to WSPRnet. Hence the jumping around, and hence the multiple locators from different stations in the SAME timeslot.? But even that does not really explain what is going on - since the most prolific reporter, K9AN, was receiving every single transmission, and his decoding software therefore must know the full 6-char correct locator, which it was uploading every time (on every band) in each 2nd message slot. Yet K9AN was still having the INCORRECT 6-char locators associated with his 1st message type in the database.? Conclusions: there are a lot of unanswered questions about what is going on and where. But to me it is clear that the Ultimate3S and its GPS are behaving 100% correctly; there is some strange behaviour either in the decoding software and/or in the WSPRnet website. I don't know which.? I don't have more answers than this, I'm afraid - this email explains all I know about this issue... perhaps some of you much cleverer brains out there than my tired confused ones, will see a way through this fog? 73 Hans G0UPL On Wed, Jun 7, 2017 at 8:31 PM, Graham <planophore@...> wrote: Indeed, this needs much more analysis. |
||||||||||||||||||||||||
|
Hans (and all),
toggle quoted message
Show quoted text
Thank you for the explanation, the picture in my wobbly grey matter is starting to gel a bit better now. I too ruled out anything like GPS jamming or QRN/QRM, what we were seeing just didn't fit. Ok, I now better understand how the U3 or other TX device encodes the six digit grid squares as well as how it is decoded. In fact, if you watch WSJT-X carefully over the course of the two 2 minute wspr frames you will see CG3EXP (or whatever call) as CG3EXP in the first frame and in the second as <CG3EXP> as displayed on WSJT-X. As to your thought that the decoding software or wsprnet is somehow guessing, that makes sense too. In the example I described above, I observed in the first of the two wspr frames that call CG3EXP was reported as having a grid of FN24eq (for example) and the second frame have the call as <CG3EXP> and grid as FN24eq. I observed this first hand yesterday afternoon when I was sitting in front of the computer and watching WSJT-X for CG3EXP spots. What that suggests and is in line with Hans' thinking is that WSJT-X is make a "best guess" and quite possibly because it is persisting these 15 bit hash codes for some time after they have been first received, maybe minutes, or hours, or (...). I can see that by persisting these hash codes for any period of time could cause such odd behaviour. This persistence is likely by design, there is an uncertainty that WSJT-X would decode two consecutive spots for the same station consistently whenever these two frame sequences are sent. It may even be that this persistence is used regardless of what band the spots are received on. This makes sense as the model of use for WSPR is typically for stations fixed in location and would drive a very aggressive methodology for "making a best guess". In one use case this behaviour could be seen as a benefit but in another as a detriment. All so very interesting. I was hoping that I might be able to sneak away and see the Polar Prince when it transited the seaway locks in Iroquois Ontario but didn't get the chance. Seems they were on the move very early besides and it looks like the ship is now in Cornwall ON for the day. cheers, Graham ve3gtc On 6/7/2017, "Hans Summers" <hans.summers@...> wrote:
Hi Graham, Alan, |
||||||||||||||||||||||||
|
Thanks Hans for the write up.? I am completely sure you are correct that the issue is with the WSPRnet and how it guesses at the extended locator based upon some data it is storing,? and/or the receiving program is also making guesses.
I noticed a couple of days ago that some of the incorrect decodes were associated with my call.? In WSJT-X there is a selection in the FIle menu titled "open log directory" and in that directory is a file called ALL_WSPR.TXT.? In that log file I noticed that I had decoded the now incorrect extended locator some time ago and was the first locator I had sent to WSPRNet.? Although my station was now sending the correct locator for the extended wspr messages,? when the 4 character messages were received and reported they still showed the incorrect locator I had first sent to WSPRnet.? I exited WSJT and deleted the log and restarted WSJT.? I do not know if that helped at all. For a guess as to what is going on,? it is easy to envision the WSPRnet software keeping a data table with fields of Callsign, reporting station, and the extended locator.? And envision some batch process that runs once every few hours to remove old data. Ron? K1URC |
||||||||||||||||||||||||
|
And, as we have discussing this topic, this morning at least, on
toggle quoted message
Show quoted text
wsprnet.org the spots for CG3EXP show only a 4 character grid for the first wspr frame and a six character grid for the second wspr frame. for example 2017-06-08 14:22 CG3EXP 14.097108 -12 -3 FN25pa 0.2 KK1D 2017-06-08 14:20 CG3EXP 14.097110 -15 -3 FN25 0.2 KK1D Something seems to have changed sometime around 2017-06-08 09:30 (approximately). Perhaps someone is listening and has taken note !?! cheers, Graham ve3gtc On 6/8/2017, "Ron Carr" <rcarr@...> wrote:
Thanks Hans for the write up.?? I am completely sure you are correct that the issue is with the WSPRnet and how it guesses at the extended locator based upon some data it is storing,?? and/or the receiving program is also making guesses. |
||||||||||||||||||||||||
|
and not much later after I made that observation did the four character
toggle quoted message
Show quoted text
grid squares also start appearing in both sequential wspr spots. cheers, Graham On 6/8/2017, "Graham" <planophore@...> wrote:
And, as we have discussing this topic, this morning at least, on |
||||||||||||||||||||||||
|
Robert, VA3ROM
Actually, in the maritime world when you observed a ship at anchor and it's AIS track from GPS data, you'll get a scatter plot whereby the ship appears to be "dancing" all over the place when you know it's anchored in one spot. GPS isn't as accurate on one would think. I've had ships give me success readings from their GPS, and when they are plotted they aren't in the same spot but can show them well out of the approve channel. DGPS is a different matter but most civilians use the less accurate GPS so +/- 15 m accuracy per fix is close enough and why you still need to have eyeballs on the bridge to avoid collisions which still occur with far more frequency in the maritime world than most landlubbers know about. Take for instance the collision with a merchant vessel with a U.S. warship and both crews could see it coming in slow motion and couldn't do anything about it (confirmation bias is usually the root cause for such collisions).
But here is just a short list of things that will cause GPS errors. GPS reflectometry is being used to model the ionosphere from above since the signal is significantly affected by ionization and it's not constant across the layer so one satellite says one then and another will say another, and a third something else or it may agree with one or the other. Sources of GPS signal errors Factors that can degrade the GPS signal and thus affect accuracy include the following: * Ionosphere and troposphere delays ¡ª The satellite signal slows as it passes through the atmosphere. The GPS system uses a built-in model that calculates an average amount of delay to partially correct for this type of error. |
to navigate to use esc to dismiss