Closed martinhpedersen closed 2 years ago
Today I managed to write some code (Linux only) that is able to successfully set the custom baudrate :balloon: :cake:.
I've tested against a SCS DR-7400 with no radio hooked up. It seems like we are able to initialize the modem, but for some reason it immediately think it's connected to HB9AK which obviously is not correct (no radio connected). See log output below.
If we can get around these issues, I plan on writing a small serial-package that we can use for now. I think it's best if we include it in this repo, under (ptc-go/internal/serial
). The internal-keyword ensures that no other package can import it (as it will be very non-generic).
martinhpedersen@duo:~/github/la5nta/pat (feature/ptc-support *)$ ptc_debug=1 ./pat connect ptc:///HB9AK
2018/02/25 14:54:29 Connecting to HB9AK (ptc)...
2018/02/25 14:54:29 >>> QUIT
2018/02/25 14:54:29 <<<
PTC-II System 68360/DSP-56303
Version V.4.0 Level 3
(C) 2009 SCS GmbH & Co. KG
2097152 bytes SRAM detected
64k words DSP-RAM detected
Packet Radio Port 1: SCS - DSP MULTI MODEM detected
Packet Radio Port 2: NO MODEM detected
BIOS: Version 2.08 detected
FLASHCALL: *SCSPTC*
*** STBY >>
2018/02/25 14:54:29 >>> MY LA5NTA
2018/02/25 14:54:29 <<<
2018/02/25 14:54:29 >>> PTCH 4
2018/02/25 14:54:29 <<<
Mycall: >LA5NTA<
2018/02/25 14:54:29 >>> TONES 4
2018/02/25 14:54:29 <<<
*** AUDIO TONES: 4
2018/02/25 14:54:29 >>> PAC MON 0
2018/02/25 14:54:29 <<<
2018/02/25 14:54:29 >>> JHOST1
2018/02/25 14:54:29 <<<
2018/02/25 14:54:29 Calling HB9AK
2018/02/25 14:54:29 Connected to HB9AK ()
^C2018/02/25 14:54:36 interruptsignal received, exiting
2018/02/25 14:54:36 interrupt mainloop: signal received, exiting
2018/02/25 14:54:36 Got interrupt, disconnecting...
^Z
[2]+ Stopped ptc_debug=1 ./pat connect ptc:///HB9AK
martinhpedersen@duo:~/github/la5nta/pat (feature/ptc-support *)$ kill -9 %
[2]+ Killed ptc_debug=1 ./pat connect ptc:///HB9AK
See commit 8f8a4aa3291aabab6d68bd6f19f82a6c65833edc for the code.
Wow.. this is really great new @martinhpedersen !!! :-) :+1:
@martinhpedersen I imagine the P4 has a slightly non-standard way of signaling its status, which might be the reason why the package thinks it's connected. Unfortunately, I cannot find a full-featued handbook for this device http://www.scs-ptc.com/en/Downloads.html . Will try to dig a bit further..
Ah, I see. Yes, the documentation for this modem is sparse. I will try to dig some more too :)
@martinhpedersen I checked in a tiny change https://github.com/harenber/ptc-go/commit/2b131a2aab772d80bad550e9dfa2cc586a8ba5ac which will print out some debug information concerning that. Maybe you can give it a try when you have some time. That should give us a hint.
Here is the output with your extra debug info:
2018/03/01 19:13:00 Connecting to HB9AK (ptc)...
2018/03/01 19:13:00 >>> QUIT
2018/03/01 19:13:00 <<<
*** STBY >>
2018/03/01 19:13:00 >>> MY LA5NTA
2018/03/01 19:13:00 <<<
2018/03/01 19:13:00 >>> PTCH 4
2018/03/01 19:13:00 <<< Mycall: >LA5NTA<
2018/03/01 19:13:00 >>> TONES 4
2018/03/01 19:13:00 <<<
*** AUDIO TONES: 4
2018/03/01 19:13:00 >>> PAC MON 0
2018/03/01 19:13:00 <<<
2018/03/01 19:13:00 >>> JHOST1
2018/03/01 19:13:00 <<<
2018/03/01 19:13:00 Calling HB9AK
2018/03/01 19:13:01 answer to L: 0 0 1 0 0 4 status is: 4
2018/03/01 19:13:01 Connected to HB9AK ()
Hi @martinhpedersen ,
strange.. status 4 is the correct status for a connected line in WA8DED hostmode. I tried to find any documentation, but there is little on the web. However, I found somewhere that channel 31 is used on the Dragon for PACTOR (although the PTCH command should overwrite that, but without documentation hard to say what it really does).
I just commited a small change (https://github.com/harenber/ptc-go/commit/3c934f2a608459fd06f9accb0bfa6bfde4b14e3a) which makes the code to use channel 31. Maybe that helps already.
I have a dr-7800 that I can test with your code. I can use Linux or Windows. Linux is preferred.
Have you looked at the code for aprsdroid? There is a successful implementation of bluetooth to serial connections. I use the scs with the software.
Looks like this serial library mikepb/go-serial could support custom baudrates. We could switch to this one, but I don't have the hardware to test it.
Nice. It certainly looks promising :) I'll look into it the next time I have a P4 on hand!
Sidenote; I think the best solution would be to find a pure Go package, because that would allow us to cross compile more easily. I belive the current serial package used also uses cgo, so it's not a very high priority. But it would certainly be nice to get rid of all C dependencies eventually.
Anybody willing to test with P4 Dragon? @Linus-007 Specifically I'd like to know if custom baud rate is working with the new serial driver (see #24). Please build fork https://github.com/blockmurder/pat/tree/feature/pactor-2.2.0 in order to get the new serial driver or checkout ptc-go develop branch.
Yes... I received a DR-7400 just yesterday. I'll see about getting go installed and build everything when I get back this afternoon. -- Update. So I tried building this with a snap install of go this morning, it failed so I'm building a Ubuntu 18:04 LTS VM to see if I can build this to test. I've no familiarity at all with go, so this may not go very far.
I just acquired a DR7800 here, and I can also test the Ethernet connectivity which is much preferred at my house. :) It also allows Linux usage with no fuss.
Does the current release support P4's now? I have not upgraded mine in quite a while.
have you reviewed this?
Am 25.04.20 um 14:07 schrieb Mitch, AB4MW:
Does the current release support P4's now?
no, it does not.
Am 25.04.20 um 14:28 schrieb Mitch, AB4MW:
have you reviewed this?
A patched kernel module would kill portability, that is not what we want. But if anyone with a P4 device wants to try to port the C code mentioned in the PDF to Go, that would speed up things.
Might we proceed with Ethernet connectivity for the 7800s? I intend to sell my PTCiiex thus i will be Windows bound once more at least for WINLINK, and that saddens me.
Am 25.04.20 um 17:10 schrieb Mitch, AB4MW:
Might we proceed with Ethernet connectivity for the 7800s? I intend to sell my PTCiiex thus i will be Windows bound once more at least for WINLINK, and that saddens me.
I have no overview, but I doubt that a lot of folks ordered the Ethernet option (neither did I, only BT). My priority would be serial (it's the default, every device has it).
It's the same control protocol over ethernet as via serial for the 7800.
The only appreciable difference in the command and plain text connect side of the P4's seems to be that it sends \r\n as line ends instead of \r, and that there is no mailbox.
Today I received my DR-7800 and immediately made some progress, was at least able to speak with the device connected through USB to a Cubietruck running Armbian Linux:
Found port: /dev/ttyS0
Found port: /dev/ttyS2
Found port: /dev/ttyUSB0
Opening USB0
Command key words:
==================
ACHeck ADdlf ADECoder Amtor ANotch ANSwer APower
AQrg ARX AT AUdio BAKup BAUdot BC
BEll BKchr BMsg BOOT Box BRightn BT
CBdetector CHeck CHOBell CHOchr CLr CMsg Connect
CONIntegrityCONType CSDelay CTExt CTrlchr CWid CWMoni
CWSpeed CWTerm CWWeight CYcle DAte DD DELete
DIR Disconn DISPlay EQualize ESCchr FAX FEc
FRee FSKAmpl Gate HAYON HCr Help JHOST
JHOST1 JHOST4 JHOST5 KISS @K LFignore LICENSE
LIN LIst Listen LOCk LOg LOGIn MAil
MARk MAXDown MAXError MAXSum MAXTry MAXUp MOde
MONitor MYcall MYLevel MYSelc NAVtex NUL OFF
OFFMessage PACket Phase PDTimer PDuplex PMONitor POSition
PSKAmpl PSKTerm PT PTCComp PTChn Qrt QRTChr
Quit RCU Read RELOad REMote RESEt RESTPar
RESTart RLe Send SERBaud SFile SHow SPAce
SQuelch STatus SYStest Term TIme TNC TOnes
TR TRX TXDelay UMlauts Unproto UPDATE USer
USOs UTcoffset VERIfy Version Write XUser Xcmd
SAP LAP
For more information type: Help <CMD> (eg: H Help)
cmd:
EOF
harenber@cubietruck:~/serial$
The same code also worked on my Macbook running Mojave (with the SCS driver installed, otherwise there is no device, seems that Mac OS does not include the FTDI driver):
Found port: /dev/cu.Bluetooth-Incoming-Port
Found port: /dev/cu.BoseSoundSport-SPPDev-2
Found port: /dev/cu.BoseSoundSport-SPPDev-3
Found port: /dev/cu.HC-05-SPPDev
Found port: /dev/cu.SCSDRAGON7800-DR4Q2I03
Found port: /dev/cu.THBoseQuietComfort35-SP
Found port: /dev/cu.THBoseQuietComfort35-SP-2
Found port: /dev/tty.Bluetooth-Incoming-Port
Found port: /dev/tty.BoseSoundSport-SPPDev-2
Found port: /dev/tty.BoseSoundSport-SPPDev-3
Found port: /dev/tty.HC-05-SPPDev
Found port: /dev/tty.SCSDRAGON7800-DR4Q2I03
Found port: /dev/tty.THBoseQuietComfort35-SP
Found port: /dev/tty.THBoseQuietComfort35-SP-2
Opening SCSDRAGON7800-DR4Q2I03
Command key words:
==================
ACHeck ADdlf ADECoder Amtor ANotch ANSwer APower
At least that is a good basis to getting those devices supported. :-)
Think I found a bug in the WA8DED implementation of the Dragon modems. Contacted SCS and they confirmed that it could be a bug, as only CRC-Hostname and not standard WA8DED hostmode has been tested. That means we have to code this CRC enhancements (the example code is in PASCAL...).
With a hint of the SCS folks (thanks DL6MAA) I could find the source of the problem, which, without going into details, was not related to the modems at all.
The CRC Hostmode is now implemented and working and I will check the code in soon. This will change the protocol between pat and all SCS modems (not only the new Dragons) to this enhanced Host mode which makes the data interchange more robust in HF environments.
I could already sent the first mails with my DR-7800. :-)
P4Dragons work fine since v2.2.0. Closing this.
Have you tested against the new firmware which supports 2G ALE linking in the 7800's?
Also, SCS intends over time to replace the WA8DED serial mode since it is very long in the tooth and generally un-needed with recent serial hardware. They have expressed no timeline for that, but just so you have it in your "data bank" for the future.
I personally just worked without it and wrote my own protocol framing that's more reasonable for what I do, but then that's not too smart in the long term.
@guitarpicva Successfully testet a PACTOR connection with the ALE version (without ALE of course, don't have a license).
And I spoke to the SCS folks: the switch away from WA8DED is currently not on the horizon. But they know me know and know that I am interested to keep the Dragons working with Pat. 73s
Excellent! That lines up with what SCS told me as well, re: the DED timeline.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, December 3rd, 2021 at 4:40 AM, harenber @.***> wrote:
@.***(https://github.com/guitarpicva) Successfully testet a PACTOR connection with the ALE version (without ALE of course, don't have a license).
And I spoke to the SCS folks: the switch away from WA8DED is currently not on the horizon. But they know me know and know that I am interested to keep the Dragons working with Pat. 73s
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Opening this issue to track the P4 Dragon (DR-7X00) support efforts.
The first obstacle is that these devices operate on a non-standard baud rate of 829440. The serial package used by ptc-go does not support non-standard baud rates. Furthermore, it is hard to do it cross platform... so we might need to write custom code for each supported platform.
For Linux, the serial-package uses termios to configure the port. It should in theory be possible to set custom baud rates through the Termios API's BOTHER, but due to implementation details in glibc this is not functioning. More info on debian bug 683826.
I have attempted to use the BOTHER flag to get tarm/serial to accept custom baud rates. It does not seem to work, probably due to the libc bug.
An alternative solution (for Linux) could be to use the linux.h kernel interface (
serial_struct.custom_divisor
). That will not work on some older kernel versions, and (obviously) a non-portable solution. It looks like this may be the only feasible solution. This is what paclink-unix is doing.A somewhat related discussion here: https://github.com/tio/tio/issues/49.