It'd be nice to be able to, say, do X.25 as well as DECNET. If I can
find the sync serial hardware for the Prime, I'd use one for X.25 there.
We HAVE to get an X.25 network going, seriously. What equipment do I need, a PAD and some kinda modem? :)
sampsa
BTW is there any particular target in mind for this? If it's for
HECnet, DDCMP would probably be more useful than the annoying
bit-stuffing protocols. But better yet would be to support everything
... no point in having to build almost the same thing again later.
It'd be nice to be able to, say, do X.25 as well as DECNET. If I can
find the sync serial hardware for the Prime, I'd use one for X.25 there.
Ditto on the IBM side and SNA or 3270 concentrator setups over "leased
lines".
De
CDN$ 59 is a good price. In the Netherlands I'd expect to pay EUR 80.
-----Original Message-----
From: Ian McLaughlin <ian at platinum.net>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 17 Jan 2013 21:11:32
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multi-floor household (DECnet) routing help needed
All this discussion got me off my a$$, and I looked around locally for a powerline ethernet device today. I found a D-Link DHP-309AV "PowerLine AV+ Mini Adapter Starter Kit" for $59 CDN.
The specifications say "up to 200Mbps speed", however plugging into a gigabit switch it only negotiates 100Mbps, so I suspect "200Mbps" is marketing-speak for 100Mbps full duplex.
Never mind, because the garage-end of my network is only 10Mbps (most of it is 10Base2 coax).
At first, I plugged them in to available power bars, but I was getting a red light on the device indicating a low signal level. I unplugged from the power bars and plugged directly into an outlet, and it works perfectly. I suspect the surge suppression features of the power bars was interfering. I'm saturating my 10Mbps circuit and I'm not getting any of the strange dropout errors I was getting with the wireless link.
$59 is a small price to pay compared to drilling holes through exterior house walls and crimping RJ45 connectors.
Ian
On 2013-01-17, at 1:14 PM, Cory Smelosky <b4 at gewt.net> wrote:
On 17 Jan 2013, at 15:45, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 1/17/2013 3:24 PM, Cory Smelosky wrote:
On 17 Jan 2013, at 15:05,hvlems at zonnet.nl wrote:
Two Linksys WAP54G units, that's what I'd do. The WAP54G is fairly old so may be cheap on EBay.
But you're not a Linksys fan, are you?
No, but from what I've recently learned, MoCa is going to be a great solution and I think it's what i'm going to go with.
I ran a wifi bridge many years ago when I lived in Philly. Never worked well and then the school across the street put in a bajillion million watt APs that used EVERY FUCKING AVAILABLE CHANNEL and my bridge just stopped working completely at that point.
That's when I was introduced to MoCA. 100mbit and solid. Also, latency is much lower than wireless.
Also, very cheap (looking now, NIM100s are $15/each on ebay but I paid $5/each for mine) and at least here in the US coax is almost guaranteed to be in place in pretty much every house so you rarely even have to do any major wire pulls.
I should probably have asked my friend who works for a local cableco instead as I lost the bid on the one. ;)
At least I got a lot of 2 I'm not patient when it comes to networking.
-brian
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=E199F50A60EA11E29…
From: Dave McGuire <mcguire at neurotica.com>
I built a Z8530-based AX.25 PAD for ham packet radio...but that was 25
years ago!
Nice!
I remember being thoroughly impressed with the Z8530, and
I've used it in several projects since then...
I'm pretty !@*^% impressed too (except for the annoying two-step register
access, which I guess is fixed in other versions). That DPLL is the perfect
thing for ham packet radio -- wish I'd known about that (I paid Real Money
for a used DUP11 about 20 years ago hoping to use it for hamming but never
got around to building the circuitry it would have taken to whip up a clock,
but it seems the Z8530 already has that and was commonly available at the
time -- dammit!).
So yes...if you're doing sync stuff with it, that might be very handy if
we do this and it goes this route.
Sync is the plan but I don't yet have anything to test against (waiting
for some trivial PCBs to come back that save me the trouble of piecing
together a Berg-to-DB25 cable for my DUV11, and I think they'll also work
for DMV11s and DUP11s, so I'll have plenty to test/debug with). So that'll
change within the next week and I'm working to have code ready by then.
I would imagine it'd be offended. ;) However if memory serves, HDLC
frames contain a few bits' worth of sequence numbers.
BTW is there any particular target in mind for this? If it's for HECnet,
DDCMP would probably be more useful than the annoying bit-stuffing protocols.
But better yet would be to support everything ... no point in having to
build almost the same thing again later.
As for config: is using the RS232 port (in async mode) too easy?
John Wilson
D Bit
On 01/18/2013 02:06 AM, Ian McLaughlin wrote:
What sort of hardware interface would you envision?
Two ports - Sync and Ethernet. Maybe a couple of status LEDs.
That sounds good, but I meant what sort of hardware on the sync serial
side. RS232 with the requisite sync clocks?
What do we need for config? Local IP address, Remote IP address,
Baud rate (because we'd need to generate clock if I'm not mistaken).
Yes. Probably not much more than that.
How do we get parameters in? Web interface or telnet CLI ? Maybe
DHCP extra parameters (no need to write a GUI, but some people will
find configuring their DHCP server to serve additional parameters
very difficult).
If people are using DHCP servers built into consumer-grade networking
equipment, yes. :-( Maybe a telnet-interfaced CLI would be best. That
said, though, I've done a very simple HTTP server under FreeRTOS, and it
could be made to do basic CGI stuff.
UDP means not having to worry about master and slave.
But it brings with it the need to deal with packet ordering somehow.
That can get complicated. Is it a good trade-off?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2013-01-17, at 11:00 PM, Dave McGuire <mcguire at neurotica.com> wrote:
What sort of hardware interface would you envision?
Two ports - Sync and Ethernet. Maybe a couple of status LEDs.
What do we need for config? Local IP address, Remote IP address, Baud rate (because we'd need to generate clock if I'm not mistaken).
How do we get parameters in? Web interface or telnet CLI ? Maybe DHCP extra parameters (no need to write a GUI, but some people will find configuring their DHCP server to serve additional parameters very difficult).
UDP means not having to worry about master and slave.
Your thoughts?
Ian
On 01/18/2013 01:37 AM, Ian McLaughlin wrote:
I'd do it with an HDLC/SDLC-capable chip like a Z8530...offload as
much from the firmware as possible, leave those cycles for
protocol handling. Unless you meant wrapping bare ?DLC frames in
packets?
I was thinking that we don't even need to decapsulate the serial
frame at all - just detect the start and end. All we're doing is
emulating a piece of wire, after all. Unless we're putting in a
fancy LCD status display, but I think that's overkill.
Ohhhh ok, that's an interesting idea; make it a "dumb" transparent
bridge. I was thinking we could do interesting translational stuff at
the protocol level, but one can't beat the utility of a dumb
get-bits-from-here-to-there bridge. I like this idea!
I have that problem as well, but I got really excited when you
mentioned it, because I am doing a lot of designs with Ethernet
now. I have a "base" design, a "hardware macro" if you will, that
I've recycled several times. It's a Philips..erm, NXP
LPC2300-series ARM7 with an on-chip Ethernet MAC, and all
supporting hardware. I typically run FreeRTOS and uIP on them.
The only things I have dev platforms are on my end are PIC and Atmel.
I do a lot of AVR stuff for work, but mostly that's maintenance of
previous controllers. All of our current stuff (and my personal stuff)
is ARM7 now. If (and I'm not pushing, or even suggesting!) you ever
want to get into it, I can give you a big head start.
I have some Zilog stuff, but I gave up on them several years ago.
Same here...after a significant investment in time, code, and blank
PCBs. Their management is incredibly, unbelievably bad. I used the
eZ80F91 in several commercial products. Great chip. Crappy tools.
Crappy company management.
However, if you're able to put together the hardware layer, and
there's a C compiler available for your platform, I can help on the
software side. I've also done some software work for a local company
that uses a TI Davinci processor.
I am, and there is, that would be great, and...wow that's cool! :-)
What sort of hardware interface would you envision?
Interfacing an ?DLC engine to that would be a cakewalk starting
from that base design as a head-start. I have a few tubes of
Z8530s in PLCC-44 packages here.
Oh oh. I think there's another project starting... :)
Oh there are just too many. ;)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2013-01-17, at 10:48 PM, John Wilson <wilson at dbit.com> wrote:
Careful -- UDP doesn't guarantee in-order delivery.
How does HDLC feel about little surprises?
HDLC information and supervisory frames have sequence numbers. There's also unnumbered frames used for control purposes.
The commercial units I found used UDP as their ethernet transport.
Ian
On 01/18/2013 01:48 AM, John Wilson wrote:
I'd do it with an HDLC/SDLC-capable chip like a Z8530...offload as
much from the firmware as possible, leave those cycles for protocol
handling.
FWIW, I'm in the middle of writing a Z8530 driver for E11 (in heavily
commented x86 code), which I'd be happy to contribute (after modifying
as needed) if you aren't already neck-deep in SCC code.
I built a Z8530-based AX.25 PAD for ham packet radio...but that was 25
years ago! I remember being thoroughly impressed with the Z8530, and
I've used it in several projects since then...but only in async mode.
So yes...if you're doing sync stuff with it, that might be very handy if
we do this and it goes this route.
We could certainly do the framer in firmware; there's a certain appeal
to that...but I'm a big fan of distributed processing, and as the iOS
device saying goes, "there's a chip for that".
Wrapping the data in UDP is simple. The HDLC layer could deal with
error detection/correction.
Yes!
Careful -- UDP doesn't guarantee in-order delivery.
How does HDLC feel about little surprises?
I would imagine it'd be offended. ;) However if memory serves, HDLC
frames contain a few bits' worth of sequence numbers. These could be
checked and buffered/re-issued to recover from most bad situations, I
would think.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
From: Dave McGuire <mcguire at neurotica.com>
I'd do it with an HDLC/SDLC-capable chip like a Z8530...offload as
much from the firmware as possible, leave those cycles for protocol
handling.
FWIW, I'm in the middle of writing a Z8530 driver for E11 (in heavily
commented x86 code), which I'd be happy to contribute (after modifying
as needed) if you aren't already neck-deep in SCC code.
Wrapping the data in UDP is simple. The HDLC layer could deal with
error detection/correction.
Yes!
Careful -- UDP doesn't guarantee in-order delivery.
How does HDLC feel about little surprises?
John Wilson
D Bit