Yes, I have tested the setup on all com ports, the screenshot was one of the tests.
In all cases (COM1…COM4 whether or not the port has a physical output) I can see the same “port lock error”.
This is the trace for the setup reset :
< exeCopyConfigFile,RxDefault,Current
> $R: exeCopyConfigFile,RxDefault,Current
> CopyConfigFile, RxDefault, Current
< exeCopyConfigFile,RxDefault,Boot
> $R? exeCopyConfigFile: Not authorized! Please use the "login" command to create a user and get authorization.
< Requesting login,********
> $R? LogIn: At least one user with a non-empty password should be available before attempting to login!
> Please use the login command with 4 parameters to create a first user and login:
> login,<username>,<password>,<factoryUserName>,<factoryPassword>
etc.
and then :
< exeCopyConfigFile,RxDefault,Boot
> $R: exeCopyConfigFile,RxDefault,Boot
> CopyConfigFile, RxDefault, Boot
After that, I restarted the p2p server :
< setPointToPoint, P2PP1, Server, COM1, 192.168.60.2, 192.168.60.1, none, "none"
> $R: setPointToPoint, P2PP1, Server, COM1, 192.168.60.2, 192.168.60.1, none, "none"
> PointToPoint, P2PP1, Server, COM1, "192.168.60.2", "192.168.60.1", None, "PD6PR8GIVAI830LLG2WL3U097O9T869LNPTZOTAX", 60, 600
There is again a hashed password. Anyway, I can define a password :
< sp2p,P2PP1,Server,COM1,"192.168.60.2", "192.168.60.1", PAP, "passwd", 60, 600
> $R: sp2p,P2PP1,Server,COM1,"192.168.60.2", "192.168.60.1", PAP, "passwd", 60, 600
> PointToPoint, P2PP1, Server, COM1, "192.168.60.2", "192.168.60.1", PAP, "81XTZL7NC1K1A7EEQZSEAR73GV391X3EFT9UV90O", 60, 600
And once again : port lock error.
The password has nothing to do with the problem since with or without password, the PPP negotiation does not start (no TX activity on the com port).
Note : I should write again that the com ports are perfectly working with NMEA, SBF, or command I/O. The problem only appears with P2P server.
The error is reported by the module itself when the p2p server is started. “Port lock” as error type probably indicates that there is a problem in the embedded system. On linux, most of the time, a lock error on pppd startup indicates that the device is already used by another process.
The port lock error is reported on *any* port, with/without password, with without a party connected on the other side.
Since I can’t imagine that the feature is documented while it does not work, I guess that there is some other parameter on the mosaic module that starts a process listening on the tty port that the P2P server wants to use. I think that the other process is *listening* and not writing since with a scope we cannot see any activity on the TX line (from the mosaic) when the p2p server is running. This situation should have a solution with some kind of tricky setup.
The other possibility is that a dead lock is preventing the p2p server to start in the module, but in this case, it would mean that the documentation describes someting that simply cannot work.
So my questions : has anyone tested the p2p feature ? with success ? if yes : what was the setup ?
kind regards, thanks for you time