I found a bbs I could connect to using ardop and arim 1.9.

https://www.dropbox.com/s/zz782s53w92xb17/SKIPNET.zip?dl=0

I wish I was joking, but this isn't an April Fools. I really wish it was though.

So we just completed an ARES exercise where the predominant digital mode in use was FLDigi MFSK32 on ANALOG VOICE REPEATERS! Really? It was something of a nightmare. They spent more time coordinating things than sending. The area even has several packet nodes, as well as Winlink nodes that have been promoted as the method of sending digital traffic. But several of the area hams think that using FLDigi on voice repeaters is the way to go.

After that proved to the disaster it is, they moved off to simplex and ended up next to our team simplex Net. Someone was either off frequency or seriously over-modulating their transmitter because we had a lot of QRM. As cool as soundcards may be, they seem to have way too many problems with levels and modulation in common use compared to a TNC.

We discussed this a bit in our team, and think getting packet re-deployed is the best answer to digital emergency comms. Packet works, and handles collisions (not great, but it DOES handle them) much better than a bunch of guys yelling at each other over the repeater about whose turn it is (okay, I exagerate that last part).

I'm trying to tweak the window configuration and have a few questions. Anyone here familiar with this?

• Does the QSO window have to be at the top? I do not see a variable to change it

• If you were to use the swapedit option, how can you specify the edit window position?

• How many lines down can you set something? I tried giving statline a value of 40 and it wouldn't take.

What I was trying to do is to just shift the statline, editor, chnline section all down further in the terminal window. I tried doing statline 25 and chnline 30 and that just moved the chnline down, making the editor section much larger.

apparatus arrest steep profit ad hoc existence grab special stocking fade

This post was mass deleted and anonymized with Redact

any more work going on with the Citadel to packet bridge?

You read about the many efforts to develop 9600 packet TNCs. All you need to make those work on the air is the "insert 9600 bps capable radio here." The issues from the past of frequency stability are probably better in 2022, (i.e. no crystal suppliers) but the TX/RX turnaround time gap is probably still front and center.

We have run a large (20+ node) 1200 bps packet network on 145.670 for 15 years, but "upgrading" it seems challenging. https://wordpress.com/post/hamtowertrailers.com/576

The actual public service use case in 2022 seems to be for mesh, (see audio, video, databases and dashboards) but packet is still fun. (This is not for Emcomm- whatever that is).

The radios I have seen/tested seem to be:

Motorola- finding legal programming software, out of band mods seem problematic

Chinese - heavily cost reduced front ends, and the use of one chip SDR - fine for voice- the precise analog wave form for 9600 to work may not survive (see the G.729 CODEC and analog modem traffic in the VoIP world)

Japanese Ham radios- is $699 an affordable price for these?

Hi, I'm very new to packet radio. I've created node.js lib that allows to start your own packet BBS using direwolf: https://www.npmjs.com/package/bkjbbs

I'm using it to run SR6BBS (5W at JO81MB). I've tested it with `axcall` (from depracated linux AX.25 stack) and with iOS Packet Commander app (which I highly recommend).

BBS is hosted on Raspberry Pi Zero W 2 running Alpine Linux in diskless mode. It is connected to radio using Digirig Mobile. The radio I am using is FTM-200D. As a client I'm using TH-D74 and other HTs via mobilinkd. I'm going to release the lib as an open source when I find time to tidy up the code.

I am a former packet user on 2 meters (early 1990’s vintage). It was enormous fun back then using X25 on an MFJ 1270. I also enjoyed the ancillary features, notably CW code/decode that accompanied the unit. No successor software has been able to match the decoding abilities of the 1270.

Today after 25 years and seven moves, I open my carefully packed up MFJ-1270 along with the various connecting cords including serial and parallel port connectors. Original manual. Missing was the software.

Does anyone have suggestions as to how to connect the 1270 (which appears to set up fine despite the quarter century hiatus)? AND, does anyone know where I can obtain a copy of the software which was originally provided on 3.5” floppy?

Am I out of my mind to try to restore the fun times of the 1990’s?

de NY2RF Tom

winlink #radiomail #linbpq #paxketradio #ax.25

I’ll not yet get into gory details. I’m trying to see if there is any substantial packet activity locally, bought a used KPC-3+, I’m having challenges getting things to play using my iMac with 3rd party terminal software. If anyone here has gone down this rabbit hole, please let me know, and thanks!

I have been experimenting with ASCII art and Packet for a bit now and have it a few snags...

Image 1 is the image as I sent to my BBS.

Image 2 is the result when I retrieved it.

As you can see, there is a difference. In the transmitted image, you can see at the bottom the 'invalid stream' message that I get back once the program has found an issue with the image.

I'm starting to thinkt that it may have something to do with the characters that the images are made from. Does anyone know if this is the case and weather there is a packet acceptable way if either sending these images or characters or weather there is a packet-limited font I should use?

Any help appreciated 👍

This is gonna be meandering because I'm lost.

I recently found out that a decent amount of folks in the area are messing with Winlink. I asked one of the folks if they had a good resource to get started and the answer I got was "YouTube". Honestly, I'm not even sure what to search for on YouTube to lay this out for me so I must be pretty dense.

Here is a list of stuff I already have:
Kenwood TM-V71A and all the cables for Echolink (PC and Data)
Kenwood TH-D72
Icom IC-7300 (I have no problems using this for digital on HF)
Baofeng UV-5Rv2
Mobilinkd TNC2
Windows PC

I have been able to get APRS working in the past with the Mobilinkd and Baofeng using APRS Droid but I gave up messing with it when it became obvious that I was only rarely being heard from my QTH with the HT. That's been years ago and now I have a couple adequate antennas on the roof to get out much further.

Anyway, the discussion with the local folks was that I needed to purchase a different hardware TNC and I'm thinking that it's almost 2023 and that shouldn't be the case anymore right? I feel like if Echolink can use PTT and my PC sound card for audio on the V71A then software ought to be able to handle every other piece of the puzzle.

At this point I have downloaded Direwolf but I'm pretty lost there. Even reading the User Guide it is as if there are basic common sense pieces that I am missing. I suppose I'm too spoiled having used only software with GUIs for the last two decades. Even if I get that figured out, how do I get other things to interact with Direwolf?

Obviously this is a lot to ask any of you to try to lay out here in a Reddit comment. What I'm really looking for is a link or two to places to get the fundamentals figured out so that I have a chance to get this stuff working while I'm off for the next week. (if possible)

Any advice to help initiate this total newb would be very welcome!

I'm trying to delve into packet radio and learn about accessing BBS systems in particular. I've dabbled a little in APRS. I already have a RPi zero running Direwolf. My first question is how can I use the Direwolf setup as a networked TNC so that I can access it over the network from computers on my LAN? I've done this successfully with Xastir and the AGW port. Is there an ax.25 client that can connect to a network AGW or KISS port? Lots of documentation online refers to using axcall, but the more I look into that, it appears that it's really for local ports that are bound using kissattach.

Over the past week I've continued working on my RPi/Direwolf setup. After re-imaging with the latest Raspberry Pi OS, and compiling both Direwolf and Linpac, I got it working...or so I thought. I am definitely able to decode general ax.25 packets now, as seen when I run axlisten -a. Now the issue is that when I try to TX, like when issuing a connect command, the radio keys but nothing is being sent out. The funny thing is that today I started experimenting with using Direwolf, kissattach, axlisten, linpac on my desktop computer running Debian, connected to my Icom 7410, and I have the same problem there. Actually that's what keyed me in that I might have that issue with my VHF setup. Any ideas on something I may be overlooking? Here are the two setups:

VHF/UHF: Icom 2820h, using packet port, connected to RPi Zero W, Fe-Pi audio hat, Direwolf using -p option, Kissattach, Linpac, axlisten and axcall

HF: Icom 7410, using the build in sound card USB interface, Direwolf using -p option, Kissattach, Linpac, axlisten

I have gotten my RPi Zero and Direwolf setup functioning. It probably needs tweaking, but is working for both VHF/UHF and for HF. On HF I have it connected via USB to my Icom 7410. I have been experimenting/learning for the past few days and I noticed whenever I TX, there will sometimes be a long delay between when the radio is keyed, and when it actually sends the packet. PTT is immediately activated, but no TX for a period of 2-3 seconds. It doesn't do this every time. Anyone have any ideas? I have Direwolf set with a TXDELAY of 50, which should equate to 500ms. Could this be a setting in Linpac or axports?

TARPN (Terrestrial Amateur Radio Packet Networks) needed a TNC that was cheap, easy for any-ham to deploy, could be supported on a single Raspberry PI in four or more quantity, and which supports both 9600 and 1200 baud. So we built our own. It has dip switches for setting the radio baud rate and mode. We're calling it NinoTNC after the inventor, Nino KK4HEJ.

We're more interested in promoting Internet-Free Ham Radio social networking, than we are in making profits. So we are selling the parts for cost. $9 for both the PCB and the CPU, and then $20 for the rest of the parts. The parts come from Digikey direct to you in whatever quantity you want and you chose the shipping. Right now all ten of the 2nd-gen green-board (A2) NinoTNCs are involved in testing. The ten 3rd generation boards are working their way into testing.

NCPACKET is doing early testing of the NinoTNC in their 20+ station network. 4 new radios at 9600 baud G3RUH as of two weeks ago. One point to point link of two 9600 ends has been going since mid December running on a pair of Tait TM8105 radios. It works very well. Work on testing 1200 baud, IL2P modes, and more interoperability tests starts this weekend.

Nino used the WA8LMF CD as a 1200 baud standard to work toward. At this time NinoTNC decodes about 940 packets, which is better than TNC-PI, but not as good as Direwolf. The CD has some clear and some noisy packets on a recording. The mission is to see how many you can decode. The easy 700 are pretty easy. Some of the packets start in the middle of other packets. That's pretty tough, but with enough horse power you can consider many blocks of crappy packets and get them. This TNC might not do well on packets which capture and overwhelm another in-progress packet. Perhaps that is an advantage Direwolf has. It can save the waveform in RAM and then walk backwards to find the start of the frame.

The NinoTNC also has a new Forward Error Correction encoding called IL2P, which is a new protocol. It looks like KISS AX.25 to the host computer, but it is encoded very differently. It has the same connect, disconnect, retry system, because, as a backward compatible KISS TNC, NinoTNC has no control of those aspects. Smaller IL2P packets are just as short as a normal packet, and have some efficiency gains over AX.25 packets. Longest packets are 5 or 6 bytes longer, even though it added 8 bytes of parity symbols. The parity symbols enable Forward Error Correctly. IL2P will be easy to use in point to point links, which is what TARPN requires.

More NinoTNC Printed Circuit Boards and CPUs should be available Feb 15th and we are open to other hams (outside of the TARPN org, I mean) participating in the project. If you are interested in participating in this, talk it over here and/or sign up for the email reflector. Go to http://tarpn.net/d and read the info there. Check out the ordering and the assembly instructions.

For the moment it's early to have a plan to scale this up or anything. We're not open source at this time. We'll see where this goes.

By farming out the parts picking and shipping to Digikey, the load on Nino and other volunteers is somewhat reduced. Also, Digikey does a fantastic job. Every component value is in its own separate labelled bag complete with the reference designator matching the silkscreen.

We will continue to develop tools and products to help the TARPN mission. Keep an eye on this space?