Port mapping importance <=10

Hello,

We recently put up several stations and since our 7-port USB hub does not seem to map ports similarly to the port mapping guide, one or several Funcube pro-s seem to end up in ports 11 or 12.

In Sensorgnome hub (we use software 2024-271) we see an error: eg. port 11 cannot be recorded (port number must be <=10). Motus website however allows us to map ports from 0 to 15 and the stations with port numbers 11 and 12 have gotten tag detections and seem to be working fine.

That rises the question of do we have to change the ports to <=10?

When trying to change the path manually, the typed in path gives an error that it’s not registered in Motus and second error is that port 11 is missing. Can anyone help with these questions?

Hi Maris, the mapping has changed somewhat since the V2 software (the one you’re using) and support for more models of Raspberry Pi.

Changes have been made to the Motus database and website to allow for ports >= 10, so you don’t need to modify the port mapping anymore if you would prefer not.

The message on the SG UI is likely a hold- over from prior to that change, when ports 10 and greater were not permitted. You can disregard that.

Thank you for clarifying that!

Hmm, have either of you tested that the data for ports >= 10 gets saved in the data files? I’m not sure it does. The server-side change happened after the last SG software release…

Thankfully it does appear to be saved properly. I just viewed a couple recent deployments and they are fine (though they may be models with a testing version > 2024-271)

But it also looks from the original GitHub issue about this that the original problem was the SG was recording all these ports, but that tagfinder was ignoring those ports. In those cases, rerunning the original data following the server side changes restored the data.

@Maris_P it may be prudent either way to double check a couple of the data files to make sure you see lines beginngin with p11(or higher) after a short trial run.

2 Likes

Hei Thorsten and Josh,

I’m a colleague of Maris’s also working with this issue. One of our stations appears to working correctly from what we can see on the Motus website and SG hub (Lista Wind Park; SG-DDC6RPI4682F, see attached images). This station also has had the most motus tag readings of any of our stations so far, so it appears to be reading tags okay. However, we continue to have the error message “port 11 and 12 cannot be recorded (port number must be <==10)”. Should we be concerned that there is an issue with our station or assume that it is working properly and ignore the error message?

A belated update to this: we made changes to the database and web interface to support data from port numbers 10-15. (Actually, the system will still process data even up to port 25, but you can’t associate an antenna with that number on the web interface).

However, though data will still be processed, the automated port mapping could be different after a reboot or power loss, meaning antenna auto-assigned 11 right now could become auto-assigned12 in the future. So if you have more than 1 antenna > 10 you’re better to map it to something to ensure consistency across reboots.

That’s nice! What is the max port number supported? Also, did you actually test end-to-end with both the old and the new SG software? Looking at the code I believe it should work, but I’m not 100% sure.

Also, note that ports >10 are assigned in the order that discovery events are triggered and propagated by the OS, which is a non-deterministic process. So if today you have two FCDs assigned ports 11 and 12 then after a reboot tomorrow they could end up as 12 and 11…

What is the max port number supported?

Tagfinder supports up to 25, though the UI currently supports selections only up to 15.

Also, did you actually test end-to-end with both the old and the new SG software? Looking at the code I believe it should work, but I’m not 100% sure.

If I recall, the old software only specifies support for that one D-link 7 port hub.

Also, note that ports >10 are assigned in the order that discovery events are triggered and propagated by the OS, which is a non-deterministic process. So if today you have two FCDs assigned ports 11 and 12 then after a reboot tomorrow they could end up as 12 and 11…

Yes we’ve been noticing this with some of the splitters we started using. At least, in theory; I don’t know how often this is actually happening. Perhaps there is some consistency in the order? Is the port path always consistent across reboots? If so, that would be a reason to remap even if it’s not necessary – at least if there is more than one >10 port.

Yes, the port path is always the same because it describes into which port each device is plugged in. This is why the mapping maps port path to number.

Thanks, I’ve clarified my comment.