P4 Dragon (DR-7x00) support

[martinhpedersen]

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: tio/tio#49.

[martinhpedersen]

Today I managed to write some code (Linux only) that is able to successfully set the custom baudrate 🎈 🍰.

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

[martinhpedersen]

See commit 8f8a4aa for the code.

[harenber]

Wow.. this is really great new @martinhpedersen !!! :-) 👍

[harenber]

@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..

[martinhpedersen]

Ah, I see. Yes, the documentation for this modem is sparse. I will try to dig some more too :)

[harenber]

@martinhpedersen I checked in a tiny change 2b131a2 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.

[martinhpedersen]

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 ()

[harenber]

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 (3c934f2) which makes the code to use channel 31. Maybe that helps already.

[Linus-007]

I have a dr-7800 that I can test with your code. I can use Linux or Windows. Linux is preferred.

[Linus-007]

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.

[blockmurder]

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.

[martinhpedersen]

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.

[blockmurder]

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.

[jpronans]

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.

[guitarpicva]

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.

[guitarpicva]

have you reviewed this?

http://www.p4dragon.com/download/Linux_DR-7X00.zip

[harenber]

Am 25.04.20 um 14:07 schrieb Mitch, AB4MW:

Does the current release support P4's now?

no, it does not.

[harenber]

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.

[guitarpicva]

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.

[harenber]

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).

[guitarpicva]

It's the same control protocol over ethernet as via serial for the 7800.

[guitarpicva]

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.

[harenber]

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. :-)

[harenber]

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...).

[harenber]

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. :-)

[harenber]

P4Dragons work fine since v2.2.0. Closing this.

[guitarpicva]

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.

[harenber]

@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

[guitarpicva]

Excellent! That lines up with what SCS told me as well, re: the DED timeline. Sent with [ProtonMail](https://protonmail.com/) 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](#3 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AD5HSD2A6EWHVFOTU5WD2IDUPCGARANCNFSM4ERGVEUQ). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).