JNOS 2.0f - HF Support for KAM, PTC, and DXP Modems ---------------------------------------------------- Maiko Langelaar, VE4KLM, June 13, 2007 1) Table of Contents ----------------- 1. Table of Contents 2. Introduction 3. Configuring the Halcomm DXP38 Modem 4. Configuring the Kantronics KAM (and subsequent) HF Modems 5. Configuring the SCS PTC II style Modems 6. Configuration of forwarding partner(s) 7. How to initiate forwarding (and/or reverse forwarding) on YOUR end 8. Watching the JNOS log and reporting problems 9. Summary of all the HFDD commands for JNOS 2.0f [Beta] 10. Concluding remarks 2) Introduction ------------ JNOS 2.0f is the best implementation yet for supporting Pactor with the Kantronics KAM and SCS PTC hf modems. I still have to upgrade the original DXP code to match the new structure used by the KAM and PTC hostmode drivers, so you will NOT be able to use your DXP with this beta version of 2.0f. A big change is that the latest drivers will automatically sense if the HF modem is in hostmode or not. If not, the modems get initialized, using another new feature - user configurable init files. Previous versions of the HFDD code allowed BBS users and the SYSOP to manually connect to remote systems, and keyboard their way through the system. With 2.0f, I have removed that. There were too many problems, and it was hard to find a good solution. Perhaps down the road ... The HFDD ports are now strictly for doing forwarding to remote systems. I have successfully forwarded with WL2K systems (mbox ki xxx), and I have been able to use a portable AirMail pactor station to connect to my JNOS server and exchange messages that way. I have not been able to initiate a forward to any AirMail stations (mbox ki xxx). The changeovers get all messed up, but I am not too concerned about this, since I believe that AirMail is usually used as a client out in the field, so it will likely be the one connecting to a JNOS server, not the other way around. One goal of this project is to see JNOS to JNOS forwarding over HF, using these new modes that I have added to JNOS 2.0. That's what I would really like to see in the end. If you want to arrange live HF testing with me, then please contact me, and let's try it out. Thank you. 3. Configuring the Halcomm DXP38 Modem ----------------------------------- For JNOS 2.0f [Beta] - currently not supported - code is being revamped ! 4. Configuring the Kantronics KAM (and subsequent) HF Modems --------------------------------------------------------- The latest version of the KAM code will now automatically initialize the KAM for you IF it senses that it is not in hostmode. Even better, the init commands are now user defineable in a config file, unique for the particular interface being attached. a) In 'autoexec.nos', add the following entries (example only) : # # Attach a HFDD - Kantronics KAM (or subsequent) HF Modem # attach asy ttyS1 - hfdd kam 4096 256 9600 # ifconfig kam desc "hf - Pactor on 20/30/40" # param kam Pactor 1 # hfdd server kam start # Note, any KAM interface names MUST start with the 3 letters, 'kam'. If you are using multiple units, you could call them 'kam1', 'kam2', or so on. b) Create new file 'kam.cfg' under jnos root directory (example only) : # # The dreaded AUTOBAUD sequence, sometimes a big pain !!! # * * * RESTORE DEFAULT # # Please do not forget to change to your OWN callsign !!! # VE4KLM # ARQTIME 1 SHIFT MODEM LFS OFF LF OFF CRA OFF CRS OFF AUTOL OFF # INT HOST RESET # Note, the above init file may be *problematic* with any AUTOBAUD sequence, so you might want to start out with several lines of just the * character to flush that part out. Results might be mixed (sorry). Hey, at least it's better than how it was done in the previous HFDD code. c) Restart JNOS (unless you entered the commands while JNOS was running). d) Power on the KAM (if it's on already, turn it off, then on again), and you might see something similar to the following in the JNOS logs : 22:19:05 - modem does not appear to be in host mode 22:19:08 - initializing ... using file - kam.cfg 22:19:08 - standbye ... this will take a few seconds 22:19:17 - modem should now be in host mode It might happen several times in a row, if the AUTOBAUD stuff get's in the way. If JNOS senses that the hf modem is still not in HOSTMODE, you will see more of the above messages. I think maybe using minicom or some other terminal program to set the serial baud rate and perm it might not be a bad idea (ie, shut off the autobaud feature). e) At this point, remote stations can try to do pactor connects to your JNOS system, OR you can initiate a forward from the JNOS side using the convention method of 'mbox ki ' - see section 6. f) Use the JNOS command, 'hfdd debug' to get a good picture of how the driver is functioning during a Pactor session. Also if things do not work as expected, the information in the logs is very useful to me. 5. Configuring the SCS PTC II style Modems --------------------------------------- The latest version of the PTC code will now automatically initialize the PTC modem for you IF it senses that it is not in hostmode. Even better, the initialization commands are now user defineable in a config file, unique for the particular interface being attached. a) In 'autoexec.nos', add the following entries (example only) : # # Attach a HFDD - SCS PTC-IIusb Pactor Modem # attach asy ttyUSB0 - hfdd ptcII 4096 256 38400 # ifconfig ptcII desc "hf - Pactor on 20/30/40" # param ptcII Pactor 1 # hfdd server ptcII start # Note, any SCS interface names MUST start with the 3 letters, 'ptc'. If you are using multiple units, you could call them 'ptc1', 'ptcII', or so on. b) Create new file 'ptcII.cfg' under jnos root directory (example only) : # # Please do not forget to change to your OWN callsign !!! # mycall ve4klm # maxerr 30 pduplex 0 listen 0 remote 0 box 0 # jhost1 # Note, the above init file may be *problematic* with any AUTOBAUD sequence, so you might want to start out with several lines of just the * character to flush that part out. Results might be mixed (sorry). Hey, at least it's better than how it was done in the previous HFDD code. c) Restart JNOS (unless you entered the commands while JNOS was running). d) Power on the PTC modem (if it's on already, turn it off, then on again), and you might see something similar to the following in the JNOS logs : 22:19:05 - modem does not appear to be in host mode 22:19:08 - initializing ... using file - ptcII.cfg 22:19:08 - standbye ... this will take a few seconds 22:19:17 - modem should now be in host mode It might happen several times in a row, if the AUTOBAUD stuff get's in the way. If JNOS senses that the hf modem is still not in HOSTMODE, you will see more of the above messages. With the PTC-IIusb modem I used, the autobaud was not an issue, and it went into hostmode the first time. e) At this point, remote stations can try to do pactor connects to your JNOS system, OR you can initiate a forward from the JNOS side using the convention method of 'mbox ki ' - see section 6. f) Use the JNOS command, 'hfdd debug' to get a good picture of how the driver is functioning during a Pactor session. Also if things do not work as expected, the information in the logs is very useful to me. 6. Configuration of forwarding partner(s) -------------------------------------- The forwarding partners are defined in '/jnos/spool/forward.bbs' file, similar to how they are defined for regular ax25 connects. The only real difference is that instead of using 'ax25' or 'c', you would use the 'h' command, ie: ------------- ve4wws ax25 430 ve4wws ve4wws mb ------------- wu3v h ptcpro wu3v wu3v packet ------------- ve4gls h dxp38 ve4gls ve4gls ------------- wg3g h ptcII wg3g wg3g ------------- Also, your rewrite file may possibly have some entries specific to your forwarding partners. For example, in mine I have to have something similar to these below (if sp wu3v @ wu3v is to work). *@ve4wws* ve4wws *@wu3v* wu3v *@ve4gls* ve4gls *@wg3g* wg3g 7. How to initiate forwarding (and/or reverse forwarding) on YOUR end ------------------------------------------------------------------ BE CAREFULL !!! THE NEXT COMMANDS WILL CAUSE YOUR HF MODEM TO START SWITCHING YOUR HF RADIO TRANSMIT ON AND OFF AT REGULAR INTERVALS. IN OTHER WORDS, MAKE SURE YOU HAVE YOUR HF EQUIPMENT SETUP PROPERLY. I'M NOT TO BLAME FOR DAMAGE CAUSED BY YOU FAILING TO FOLLOW PROPER PROCEDURES FOR SETTING UP YOUR HF EQUIPMENT. YOU HAVE BEEN WARNED !!! ALSO, I DISCOURAGE UNATTENDED (AUTOMATIC) FORWARDING ! You should be there, especially since the KAM has no way of knowing if the frequency is busy or not. The PTC supposedly does too, BUT, having been there, I know by ear if a frequency is in use or not - CW and PACKET still counts :-) Important : If you have ANY pactor (hfdd) forwards defined in the forward.bbs file, then STAY AWAY from using the generic 'mbox kick' and instead keep the kicks to individual stations. To initiate a forward (if you have messages or bulletins waiting to be sent to the remote station), then simply use something like this : mbox kick wu3v If you have no traffic to forward TO your remote station, but you want to do a reverse forward (to pick up anything from THEM), then use this : mbox kick Wg3g Note : note the first letter is CAPITALIZED in the callsign. That is how JNOS does a reverse forward. Capitalize the first character of the remote station. Believe it or not, that's all there is to it ! 8. Watching the JNOS log and reporting problems -------------------------------------------- Be warned, the JNOS log will get filled up with the HF stuff. It's there on purpose to help me see how things are running. With JNOS 2.0f it's not as bad, since there is a new command, 'hfdd debug', that toggles whether the log gets debug data or not. If you run into problems, try and explain them to me as detailed as possible, and include the JNOS log for me to analyze. Another hint while you are forwarding with a remote station (AFTER you connect to them, or they have connected to you through the HF server), you can use the command, 'look ', from the sysop (F10) console, and actually follow the entire FBB forward session as it moves along. This is a great way to learn the FBB protocol. Sometimes this information can be helpful to me as well. 9. Summary of all the HFDD commands for JNOS 2.0f [Beta] ----------------------------------------------------- Jnos> hfdd "hfdd" - takes at least one argument Jnos> hfdd ? valid subcommands: server debug Jnos> The basic commands currently shown are : hfdd debug - toggles the debug flag, default is off. If you enable the HF debugging, the JNOS log will start logging more detail on any HFDD (Pactor) activity. hfdd server [iface] [start|stop] - starts the hfdd service for the particular port (interface). The stop option is historic, and does nothing. There are some (currently) hidden (development) commands, as follows : hfdd server [iface] kick - in case hfdd service seems hung on the modem attached on the passed iface (port). hfdd server [iface] exit - kick the modem out of hostmode for the modem attached on the passed iface (port). If the hfdd server seems to have lost touch with the modem, you can either power the modem off or on, or you can try this, which *should* force JNOS to reinialize the modem using init file. hfdd server [iface] unproto - send an FEC Pactor broadcast out the modem attached to the passed iface (port). The text transmitted is "INTERNET GATWAY ". * only works on the KAM right now, the code for PTC is there, but is incomplete. 10. Concluding Remarks ------------------ The HFDD support in JNOS 2.0f is definitely better than any previous release, but still has a ways to go - but I'm quite happy with it as it is. That's it for now. Have fun, let me know what you think, feedback is very welcome. I don't care if it's good, bad, or ugly, or critical of design, or whatever. It won't get better if people don't bother telling me what the issues are. Sincerely, Copyright (c) June 13, 2007 by Maiko Langelaar / VE4KLM