Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.
Grant Taylor <gtaylor@tnetconsulting.net> writes:
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.
Hi, Grant.
First over on UUCP, now here!
Well, I still hang out here but I am not every active.
To the best of my knowledge there is no AX.25 activity anywhere
around me. (Heck, I can't even find an active 2 meter repeater within
my range.)
I miss the days when I ran digipeaters on mountaintops and saw massive amounts of traffic.
I had a lot of stuff I thought would be interesting with AX.25 but
it seems everyone else got bored of it and with the advent of the
Internet all but gave up.
And don't get me started on the strong NIH syndrome that infected it.
At least around where I was.
Hi, Grant.
First over on UUCP, now here!
I have a background project, fiddling with a protocol for packet
radio which scales. Everything is a multicast group (helps with roaming,
as well as the usual benefits) and a CDN protocol with idempotent
semantics so nodes can opportunistically glean/cache content as it goes
by on the air.
Wrote an air/terrain emulator, and was originally
going to use standard AX.25 TNC operations to put packets on the
air. But the emulator showed that the collision and hidden transmitter problems are just horrible in any but the lightest use. So I've been
most recently working on an explicit TDM layer in place of what a TNC
would do. So standard TNC's are out, but I hope to come up with a
protocol which would work pretty well in, say, a disaster net.
73's,
Did you know that UUCP works fine over AX.25. :-)
On 1/7/21 4:23 PM, Bill Gunshannon wrote:
Did you know that UUCP works fine over AX.25. :-)
I would expect that it would.
I can sort of see how to do it with raw AX.25 as well as with Net/ROM or ROSE.
Different UUCP protocols might actually be advantagious to AX.25. Though
I suspect that AX.25's error detection and correction would provide a
fairly clean link.
I wonder if there would be any way to leverage AX.25's broadcast nature
to have UUCP send data to multiple nodes, a la. Usenet data feed.
On 1/7/21 11:22 AM, Bill Gunshannon wrote:
Well, I still hang out here but I am not every active.
I've been subscribed to the newsgroup for quite a while. But my message was the first one in my servers 2+ year history in the
alt.ham-radio.packet and free.packet.radio newsgroups.
To the best of my knowledge there is no AX.25 activity anywhere around
me. (Heck, I can't even find an active 2 meter repeater within my range.)
I'm sort of surprised that there isn't a 2m repeater in range.
I'm also a little surprised that there isn't any APRS activity.
I miss the days when I ran digipeaters on mountaintops and saw massive
amounts of traffic.
I know of digipeaters. Though I'm evaluating Net/ROM vs ROSE for
something I'm thinking about doing.
I think that Net/ROM might be nicer in that it has automatic routing vs
ROSE which is completely manual routing.
Though I like the fact that
ROSE is actually X.25 implemented on top of AX.25. At least, as best as
I can tell.
I'd sort of like a private X.25 cloud.
I had a lot of stuff I thought would be interesting with AX.25 but it
seems everyone else got bored of it and with the advent of the
Internet all but gave up.
*nod*
One of the reasons that I got into ham radio was the communications
ability that didn't depend on the Internet.
And don't get me started on the strong NIH syndrome that infected it.
At least around where I was.
I don't get the Not Invented Here mentality. I've long been a fan of standing on the shoulders of giants.
I wouldn't know where to start if you were trying to avoid TNC
Usenet feeds do not go to multiple sites in a single stream.
Connection is made to each peer and news transferred.
Prior to this the only traffic I have seen in any of the ham radio
groups has been garbage telling people (repeatedly ad nauseum)
to visit a web site to read about what they posted as a topic.
Worse than the last packet I saw which was DX Cluster Broadcasts.
(which, technically, should be illegal as they are broadcasts!)
And I have set up a scanner to cover all the 2 meter packet freqs
and never hear a thing.
I see local (well, within 10 miles of me) APRS activity if I look
online, but I have yet to figure out just what APRS is supposed to
be doing. Not sure I want everyone to know where I am all the time.
Played with both. Think ROSE would have been nice but it never caught
on and never saw the activity that would have helped it develop into something really usable. NETROM is OK but has a few warts, too.
Howie-Code would have been nice, too, but it got even less attention
that ROSE.
The only things I ever saw it running in were my DR-200 digipeaters.
I tried a few times to get the firmware from PACCOmm but, apparently,
they lost it. I contacted Howie Goldstein N2WX a couple times but
could never convince him to release any of his code. Too bad really
because it was a decent idea.Oh yeah, and then there is also TCPIP
but that kinda faded with real TCPIP on the Internet. I assume by
now my address allocations are all gone.
If it had a chance it might have developed good routing, after all,
it is using the same concepts as the phone system and that seems to
route connections pretty well. But it died on the vine just like
the rest of Packet Radio.
Implementing AX.25 on top of X.25 seems rather silly as they are
the same basic protocol with differences to meet legal limitations.
ROSE is the OSI Networking concept running on top of AX.25 instead
of X.25.
There are lots of good reasons to use OSI but in the industry TCPIP
beat it out.
Not exactly sure what that means, but then I am not a fan of "The
Cloud" so it could be something simple I miss.
I saw that as a good idea, too. But even in limited environments
it met a lot of resistance. Back in the days before AX.25 I was
a big RTTY guy. Probably because I did it professionally in the
Army for many years. I was a Class C MARS station in the north of
Germany on my last tour there with the Army (1977-1979). I spent
many nights relaying traffic from other remote MARS Stations and
the Gateway Station in Pirmasens, Germany. When I came back to the
states I didn't continue with MARS. Then after my Army time ended
and I was back home and doing packet including running digipeaters
with connections all over New England my dad, who was a MARS operator
and had seen my packet stuff (I once connected to a VAX in central
NJ from his home in Wilkes-Barre, PA using 1200 baud packet) asked me
to come down to the PA MARS Conference at Carlisle Barracks and talk
to them about the capabilities of AX.25 in their environment. I did.
I talked about the ability for MARS, in conjunction with the Corps of Engineers, who have remote radio sites all over the United States,
to set up a functional data network not reliant on the phone system
and that would remain functional even during disasters.
They were impressed and convinced me to join MARS again. I did.
Less t6han a week after I got my MARS Operating Permit I was contacted
by the local (NEPA) MARS Manager and told he was not interested in
any network I had in mind and he was the boss so I should just drop
the iddea completely. I never joined a net or filed a monthly report
and my membership eventually expired.
Remember what I said about NIH? The same was true when I tried to
get TCPIP activity among the local Ham Community. The had W0RLI BBSes
(which actually were nothing but existing old tech re-invented, badly)
and had no interest in anything more modern that CW.
See above. :-)
Both the guts of Direwolf (great SW, BTW) or just soundmodem will give
you lots of raw functionality--FSK coding up through packet assembly.
But then on top of it you run your own queues and logic for when to
key up.
On 1/8/21 5:49 AM, Bill Gunshannon wrote:
Usenet feeds do not go to multiple sites in a single stream.
Connection is made to each peer and news transferred.
It depends what type of Usenet feed it is. Traditional UUCP & NNTP
feeds are one-to-one.
However there is multi-cast NNTP. There used to be Usenet via satellite broadcast.
So ... I'm convinced that Usenet is /capable/ of being one-to-many.
I ran a news server at the University I used to work at (frequently
made it into the top 100). Had a satellite feed from Cidera.
Was still really just point to point under the hood. Just asymmetrical
as we connected back to them over the Internet to confirm reception.
Theoretically, News could be sent as one way broadcasts but the amount
of data that would need to be sent would increase considerably.
On 1/8/21 10:35 AM, Bill Gunshannon wrote:
I ran a news server at the University I used to work at (frequently
made it into the top 100). Had a satellite feed from Cidera. Was
still really just point to point under the hood. Just asymmetrical as
we connected back to them over the Internet to confirm reception.
The fact that each subscriber receives a separate stream in the
satellite broadcast really surprises me.
My understanding is that it was a single encrypted broadcast that
everybody received. People that had a current subscription had what was necessary to decrypt the single broadcast to extract data and feed it to their news server.
Duplicating that stream would be massively redundant data and extremely inefficient.
Theoretically, News could be sent as one way broadcasts but the amount
of data that would need to be sent would increase considerably.
Why would sending a single broadcast increase the data?
I thought that soundmodem was effectively a software TNC relying on the sound card. So ... even that doesn't avoid the TNC functionality.
Perhaps it's a start, as in prior art, to base new creations from that themselves function in lieu of a TNC.
But then on top of it you run your own queues and logic for when toQueuing could mean a lot of different things. Is it messages waiting in line to go out? Or is it just waiting for clear air time to send a
key up.
frame? Or is it something else.? That definitely starts stretching and changing definitions.
Lot's additional data to make it FEC.
And then you have all the requested re-transmissions from subscribers
who, for one reason or another missed an article.
The more subscribers the larger the amount of data needing to be
resent.
I think multi-cast works best with data that can live with packet loss.
If you lose one or two packets from a five minute segment of a movie
or a sports event you likely won't notice it. If you lose one packet
from a Usenet feed you have completely lost at least one article.
Maybe more than that depending on how stuff is batched and sent.
I agree. You can call it a TNC function, but it's very different
from the behavior you'd see from an AX.25 TNC.
I don't have any new ideas on how to FSK and build a framed packet.
So I'm OK with leveraging the existing code. And I'm OK with using
a sound card, because it's the only HW I have to do this anyway!
It's built around a formal TDM regime. Each station gets slots,
and that controls when they can transmit.
I purposely built the content level so you can have a packet for a
given chunk, and _while waiting_ for your slot to transmit it, see
something which obviates your need to put it on the air. And then
cancel it out of your queue, thus changing your behavior at your
next transmit slot. Sending a subsequent chunk, or handing back the remainder of your time allocation.
Also using TDM, you transmit when your time slot(s) come up, in a
regime where you're guaranteed that--within your network--no other
member will be transmitting simultaneously. So no collisions, not
even hidden transmitter ones.
Which, as I noted, my simulations made me aware of how quickly the
AX.25 air transmit algorithm can fail to scale.
You can reduce collisions with custom air collision parameters, but
you're vastly reducing the efficiency of your network--which is a
scaling failure again.
On 1/8/21 11:39 AM, Bill Gunshannon wrote:
Lot's additional data to make it FEC.
I would think this would be a compounding / multiplicative effect for
each additional article stream.
And then you have all the requested re-transmissions from subscribers
who, for one reason or another missed an article.
I would expect it to be more along the lines of here it is, catch it or
get it elsewhere.
The more subscribers the larger the amount of data needing to be resent.
I would expect that very little data would be re-sent. Either you got
it when it was originally sent or you didn't. If you didn't get it,
then it's up to you to get it elsewhere.
I think multi-cast works best with data that can live with packet loss.
I feel like Usenet feeds very much qualify as this. Assuming that the ""packet is a message.
If you lose one or two packets from a five minute segment of a movie
or a sports event you likely won't notice it. If you lose one packet
from a Usenet feed you have completely lost at least one article.
How is this different than a perfectly functional connection to a peer
not offering you an article, perhaps because their filter gobbled it up.
This is why you want to maintain multiple peers, so that you can get articles from peer #2 that you didn't get from peer A.
Maybe more than that depending on how stuff is batched and sent.
Yep.
My working understanding is that soundmodem would be comparable to a TNC
in KISS mode. Meaning that it's doing the modulation & demodulation and framing.
I can see how soundmodem probably doesn't have more of the features
beyond KISS that a TNC would have, particularly a TNC with the Net ROM
in it.
I would be afraid that strict time division multiplexing would tend to
end up under utilizing the connection. Especially if you have multiple stations, each with their TDM slot, that didn't need to transmit anything.
But I do think that there are scaling issues. Or at least issues that
need to be addressed related to physical scaling. At the moment I'm thinking stations A, B, and C, in a line but far enough away that the
signal propagation time between A and C means that even when A completes transmitting in it's time slot, it's signal can take long enough to
reach C that it's now into C's time slot. But, I suppose that you can account for that in your scheduling algorithm.
Which, as I noted, my simulations made me aware of how quickly theI feel like stock AX.25 will have the same scaling problem that old 10Base{5,2,T} Ethernet had. More talkers means more collisions.
AX.25 air transmit algorithm can fail to scale.
Yep.
Grant. . . .
Well, let's see... 5-10% extra bits over having to resend the entire article because you missed one packet.
If I have to have a more reliable feed to fill in the gaps what is
the advantage of taking the unreliable multi-cast feed?
See above. There isn't a system in place to request particular
individual articles. If you miss an article how would you even know
of its existence to request it?
And a feed missing multiple articles is really pretty worthless.I disagree.
But, the packet is not an article. Articles vary in size and
consist of a lot of packets. Packets are individually identifiable. Articles are not identifiable until they have been received and are
known to be complete.
That's why most admins have more than one feed.
What if the multi-cast feed filter gobbles up an article? In either
case, what if an upstream site gobbled up the article.
There is more to running a successful Usenet site than most people
think.
I did it for a long time. it's a labor of love because you never
really get any credit for the accomplishment.
Only complaints when things go wrong like an article being missing.
:-)
And one needs to select reliable peers. I fear the multi-cast
would soon find itself with no subscribers. Especially when you
realize that even if it worked you would still need direct peer to peer connections to send your traffic out. back when bandwidth was an issue
this might have been of more value (thus the reason we had our Cidera
feed) but today with traffic being much lower volume and bandwidth
being orders of magnitude more than it was it just isn't of any value.
If you have any sort of higher level regime to guide when to key up,
there's no way to tell the TNC about it.
Because the queues and TX decisions are up on your host, you have
full control over all of the issues.
Hypothetically, you could add lots of protocol to the KISS standard
to address this. But it's much less simple--and almost any modern
CPU doesn't need the offload anyway.
Yes, you've exactly put your finger on why I spend a LOT of time on
the protocol design! Can I make it not suck? But my simulations of
current TNC air usage tell me that sucks, too, which convinced me to
try my hand at it.
Yes, you're exactly thinking into the design space along my lines.
Although CSMA/CD at least had the *CD* part to much more efficiently
back off. There were some studies done which showed that old ethernet
was quite non-intuitively efficient even on a heavily used wire.
Like into ninety-something percentile utilization.
Thanks for your comments, much appreciated (and motivating).
On 1/11/21 6:37 AM, Bill Gunshannon wrote:
Well, let's see... 5-10% extra bits over having to resend the entire
article because you missed one packet.
I think that we are talking past each other.
My understanding of (the germane portion of) your statement was about multiple subscribers having independent feeds vs re-using a common feed.
I agree that adding 5-10% extra bits (per feed) to provide some
redundancy to avoid loosing part of the feed is a good idea.
I think this applies to any and all feeds, be it one shared feed or
multiple non-shared feeds.
If I have to have a more reliable feed to fill in the gaps what is the
advantage of taking the unreliable multi-cast feed?
You touched on it below. Bulk inexpensive (faster) feed for (hopefully) 80% (or more) of the traffic. Reducing the demand on the (slower) more expensive feed.
See above. There isn't a system in place to request particular
individual articles. If you miss an article how would you even know of
its existence to request it?
You quite likely wouldn't.
And a feed missing multiple articles is really pretty worthless.I disagree.
But, the packet is not an article. Articles vary in size and consist
of a lot of packets. Packets are individually identifiable. Articles
are not identifiable until they have been received and are known to be
complete.
I agree that there are technical differences. However, the packet effectively becomes an article.
It really didn't matter if an individual identifiable packet was corrupted. Chances are quite good that it would result in the loss of
an article. Given the historic one-way nature of satellite
transmission, you couldn't effectively ask for retransmission of the
packet anyway. Thus you still lost the article.
That's why most admins have more than one feed.
Yep.
Get 80% (or more) of the bulk traffic via the inexpensive and possibly somewhat unreliable feed so that you only need to get 20% (or less) more expensive and more reliable feed.
What if the multi-cast feed filter gobbles up an article? In either
case, what if an upstream site gobbled up the article.
As you say, that's (one of the reasons) why you want multiple feeds.
There is more to running a successful Usenet site than most people think.
Yep.
I did it for a long time. it's a labor of love because you never
really get any credit for the accomplishment.
How is this any different than running a DNS / email / web / ... server?
;-)
Only complaints when things go wrong like an article being missing. :-)
Isn't that the truth.
And one needs to select reliable peers. I fear the multi-cast would
soon find itself with no subscribers. Especially when you realize
that even if it worked you would still need direct peer to peer
connections to send your traffic out. back when bandwidth was an
issue this might have been of more value (thus the reason we had our
Cidera feed) but today with traffic being much lower volume and
bandwidth being orders of magnitude more than it was it just isn't of
any value.
Yep.
One reason to use something like this today would be if the satellite
feed got articles to you sooner than other peers. Possibly because of fewer hops (peers) for the articles to pass through.
Another reason might be if the satellite feed was full Usenet feed, including binary, when other peers were not full feeds.
Well, I think the actual problem is better explained by a comparison.
Think of your multi-cast idea a UDP. You send I receive. If I
miss one you don't know and I don't know. The data would be lost.
Typical NNTP Peering is like TCP.
You connect, handshake and you then proceed to send me sequencedAh, but there is a chance of data being missed in transmission.
data. if I miss one I can identify it and ask for it to be resent
so I have the complete stream. Every Article you send is identified
and acknowledged. No chance of data being missed in transmission.
With the broadcast system you have no idea if I have received anything
and I have no idea whether or not you actually sent me anything.
Slower? My home internet connection is faster than and broader than
what the whole University had and that is including NNTP prior to
the Cidera feed. Times have changed.
You realize that would pretty much make Usenet useless. What good
are discussions with missing pieces?
See above. What if you had not received my last reply? You would
likely assume I had opted out of the conversation. Which would not
have been true.
No, the packet size is set by TCP/IP. A 5 meg article (yes, there
have been articles that big) is broken into smaller pieces using
TCP/IP. Even if we assume the sequence number can be determined
(I really have never looked in depth at multicast as Nothing I have
ever done used it) it is one way communications and I can't ask for
it to be retransmitted. Packet is lost, Article is lost.
Feed has a hole in it. Your users are very unhappy.
Which is why no site ever relied strictly on satellite for feed.
You still need old fashioned NNTP Peers.
20 years ago, maybe, but there is no "more expensive" feed today.
A satellite feed would cost more than even a cable modem connection
today and not even come close to the bandwidth.
And a multicast feed over the internet would cost the same as peer
to peer sites.
email, DNS are requirements for pretty much any operation today.
Some would argue the same for a web server. Few if any would argue
the same for usenet.
Even 20 years ago the satellite didn't get them there sooner.
And, today, there are no hops. Your peers connect directly to you.
If you pick good peers the satellite could end out sending a lot of
articles you already have. Depends on who they peer with.
To be honest, I am not sure there even are satellite feed any more.
But I thought you were arguing for multicast which is not really the
same as satellite. multicast would still come in over your internet connection. So, what would be the point?
If you have any sort of higher level regime to guide when to key up, there's no way to tell the TNC about it.I wonder if one could hack soundmodem (et al.) to allow the computer to physically control the keying via another port, be it serial or GPIO
with appropriate support circuitry.
I could see a hat for a Pi that connected to microphone in port on a
radio and had another port to hook the microphone to. Thus the Pi could control keying via GPIO and still function as passthrough for normal mic usage.
I recently watched a video on ALOHAnet and I suspect it's worth 11
minutes of your time. I believe it specifically talked to utilizing
unused bandwidth in traditional TDM schemes. I don't recall the particulars, but I do recall thinking it was novel.
soundmodem is entirely software, so the computer has _always_ had
control of the TX line.
These days I expect Raspberry Pi-ish devices will dominate, which
generally give you plenty of GPIO lines.
In any mobile client, you also need a notion of S/N from your decoder,
so you know when to initate a transition to a new connection point.
Neither soundmodem nor Direwolf provides this (and KISS has no place
to include such a metric), but I've spotted the code points where
this could be gleaned.
I'm still curious how well these:
http://www.dorji.com/docs/data/DRA818V.pdf
might work in practice.
My interest is towards fully integrated solutions, not treating packet
like a fringe Frankenstein mode. I have some stuff breadboarded,
but then turned my attention to the protocol side. My first ideas
didn't pass the laugh test under simulation, which sent me back to
add on an entire TDM layer.
Which means you can't use TNC's, nor KISS. A pity, but it doesn't
matter how easy it is to use something which doesn't work.
Oh yes, as an old networking guy, I read their papers when they
first came out. They were brilliant for pioneering in this space,
and then writing very approachable papers on the issues they found.
But, honestly, I don't recall them doing formal TDM allocations.
I'll swing back through the articles.
Thanks,
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.
I recently watched a video on ALOHAnet and I suspect it's worth 11
minutes of your time. I believe it specifically talked to utilizing
unused bandwidth in traditional TDM schemes. I don't recall the particulars, but I do recall thinking it was novel.
Link - ALOHAnet: Grandfather of All Computer Networks - Computerphile
- https://www.youtube.com/watch?v=oKrUGRVwFBI
I took a few minutes and re-watched the video. The method they used was simply collision detection and random back off & retry.
Thanks--that matches my memory of what they used.
Actually, I don't think "collision detection" is the right term.
They would listen for a carrier, then key up after some interval of
a clear channel. CD is the technique for _while transmitting_ to
detect that somebody else keyed up too. I'm not aware of any good
radio ways for doing that (on Ethernet it was clever to think of it,
but trivial to implement).
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM,
particularly on Linux.
I have an interest in getting a HAM license and trying my hand at packet radio.
I have an interest in getting a HAM license and trying my hand at
packet radio. It's a fascinating subject to me. I will read this
thread with great interest.
Hi Daniel,
On 2/2/21 1:14 AM, Daniel wrote:
I have an interest in getting a HAM license and trying my hand at
packet radio. It's a fascinating subject to me. I will read this
thread with great interest.
I encourage you to get your license.
Feel free to ask -- either here or email -- if you have questions.
I'm happy to (try to) help.
I can highly recommend the ARRL's license manual. -- Since you're
just getting started, you are looking at Technician.
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM, particularly
on Linux.
Hi Grant,
OG USENET poster/ham radio enthusiast here. Just got back on for the
first time since 2003 when my ISP killed it's NNTP servers.
Never done packet, but it's something I want to try, which is why
I'm here.
I will probably use an old laptop runing some flavor of *nix, so I'd
love some thoughts/suggestions/tips.
On 4/8/21 4:44 PM, OldbieOne wrote:
Hi Grant,
Hi OldbieOne,
OG USENET poster/ham radio enthusiast here. Just got back on for the
first time since 2003 when my ISP killed it's NNTP servers.
My ISP's loss of NNTP service is how I got started hosting NNTP /
Usenet. (The local university they got their service from discontinued
the service.) I've since moved and now run a couple of other Usenet
servers. All because someone else discontinued the service. Go figure.
Never done packet, but it's something I want to try, which is why
I'm here.
I've not done anything with packet yet. I'm still doing some reading
and learning.
I have picked up an RTL-SDR BLOG (brand) SDR and gotten it to work on my >contemporary Gentoo Linux box. The various command line utilities and
gqrx (GUI with waterfall) all worked for me. Life got busy and the
equipment is waiting on me to get back to it.
I will probably use an old laptop runing some flavor of *nix, so I'd
love some thoughts/suggestions/tips.
I'm *FAR* from being qualified to offer any suggestions. But, see
above, I do have some hints at life and will be trying packet Any Day Now™.
I don't have an SDR yet, but was planning on using Baofeng UV5R.
I am more than a little curious about them though, so will probably
pick one up when they're available again on Amazon. Right now it
seems they're out of stock with no ETA.
I work in the tech world, so should have acquired one years ago! But
I gave up radio as a hobby in my late 20's, came back into it in my
30's restoring antique radios, and now returning to amateur radio.
Been feeling pretty nostalgic lately, which is why I came back on
USENET after finding a free servie that allows you to post up to 40
messages a day. No crossposting, and no binaries, but since I'm doing
this right now from a Windows 95/DOS PC I just built for retro-gaming,
and am using Outlook Express 4 to connect to the USENET service, it's
a miracle I can even make a server connection in the days of SSL now!
On 4/8/21 5:55 PM, OldbieOne wrote:
I don't have an SDR yet, but was planning on using Baofeng UV5R.
Hey, if it works for you, go for it.
I watched a few videos from ModernHam KN4MKB >(https://www.youtube.com/c/ModernHam/videos) who got started with a
Baofeng and did a lot of cool things with it. He might have some tips & >tricks.
I got started in 2m with my Wouxun HT. I'm planing on seeing if I can
decode packet with it too.
I am more than a little curious about them though, so will probably
pick one up when they're available again on Amazon. Right now it
seems they're out of stock with no ETA.
ACK
I work in the tech world, so should have acquired one years ago! But
I gave up radio as a hobby in my late 20's, came back into it in my
30's restoring antique radios, and now returning to amateur radio.
Eh.... Just because you work in tech doesn't mean that you necessarily
want to recreate in tech too. Maybe you do, maybe you don't.
Been feeling pretty nostalgic lately, which is why I came back on
USENET after finding a free servie that allows you to post up to 40
messages a day. No crossposting, and no binaries, but since I'm doing
this right now from a Windows 95/DOS PC I just built for retro-gaming,
and am using Outlook Express 4 to connect to the USENET service, it's
a miracle I can even make a server connection in the days of SSL now!
:-)
Sounds like AIOE and looking at your Path: header, yep your message came
from AIOE. There are some other options if you ever run into the 40
messages per day. I don't personally know if it's 40 per calendar day
or 24 hour period. If you ever want to know about other options, drop
me an email. I'm more active in the Usenet community than I am in radio
at the moment, including running a pair of Usenet servers.
Yes, SSL ~> TLS is marching on and going to become more of a problem for >older systems. There are some options. Stunnel and a couple other
proxies come to mind. There's always setting up your own server that
doesn't require TLS. }:-)
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM,
particularly on Linux.
Grant Taylor <gtaylor@tnetconsulting.net> writes:
Hi,
Is there anyone lurking in the packet radio newsgroups any more?
I'm looking for someone to chat with about AX.25 / Net/ROM,
particularly on Linux.
I am here, a new one actually. I don't have my ham radio license yet,
but plan on studying for it shortly.
I have a big interest in packet radio and getting started hosting my own
bbs and messaging rig. I know some hobbyists working on adapting some interesting technologies to improve it.
| Sysop: | KJ5EKH |
|---|---|
| Location: | Siloam Springs, Ar. |
| Users: | 10 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 78:36:08 |
| Calls: | 32 |
| Files: | 76,049 |
| Messages: | 59,737 |