Tiny-2 TNC Kit
VE6TN on Shaw IDC
9600.
I am a member of TAPR. Unfortunately, they no longer sell a normal Tiny-2
Kit, although they do have the 9600 bps one.
Any reference where I can order a TNC kit would be appreciated.
Barry Middlebrook
VE6TN
ve...@rac.ca
Steve, K5OKC
>
> I want to build my own Tiny-2 TNC. Mainly for 1200 bps but an option for
> 9600.
Many of the chips are no longer available. Go take a look
at the AGWPE. The sound card will do all you need.
James Alexander
you might take a look at the old baypac BP2M, I have one and it works ok.
luc...@eternal-flames.gov
If you don't mind leaving your computer running all of the time.
Of course with a TNC, you don't even need a computer.
Rob Janssen
A TNC is a computer. But a very small one, and with software that does
little on application level. When you want to do something useful,
you quickly will need a computer attached to it. (some versions provide
a limited BBS but that's about it)
Hmm, I still have that project of downloading an application into a TNC,
still amazed that this does not exist yet.
Rob
--
+--------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWW: http://www.xs4all.nl/~pe1chl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8ZAA.#NBO.NLD.EU |
+--------------------------------+--------------------------------------+
luc...@eternal-flames.gov
wrote:
>> If you don't mind leaving your computer running all of the time.
>
>> Of course with a TNC, you don't even need a computer.
>
>A TNC is a computer.
True. But then so is my digital watch.
>But a very small one, and with software that does
>little on application level. When you want to do something useful,
>you quickly will need a computer attached to it. (some versions provide
>a limited BBS but that's about it)
I totally agree with you. But that's not the point I was making.
The posting I responded to was suggesting that a saound-card based
system was as good as a TNC based system. It plainly is not. With
the latter you can leave the TNC (and radio) running, without an
additional computer and still enjoy the benefit(?) of a mailbox.
Additionally if your TNC has a K-node, you are providing a facility
which others in your area can possibly make use of.
With a sound-card based system, though you can still have a mailbox
etc. All of that stops when you turn your computer off.
Nick.
Rob Janssen
>>But a very small one, and with software that does
>>little on application level. When you want to do something useful,
>>you quickly will need a computer attached to it. (some versions provide
>>a limited BBS but that's about it)
> I totally agree with you. But that's not the point I was making.
> The posting I responded to was suggesting that a saound-card based
> system was as good as a TNC based system. It plainly is not. With
> the latter you can leave the TNC (and radio) running, without an
> additional computer and still enjoy the benefit(?) of a mailbox.
> Additionally if your TNC has a K-node, you are providing a facility
> which others in your area can possibly make use of.
> With a sound-card based system, though you can still have a mailbox
> etc. All of that stops when you turn your computer off.
Many amateurs use a TNC to connect to others and to application systems,
like a BBS or DX cluster. They do not really benefit from using a TNC
instead of a soundcard (on a modern computer), as they need the computer
for their keyboard/screen anyway, and they cannot do anything useful when
the computer is turned off.
I leave my computer on all the time, and I use an SCC card for packet.
But for a small standalone application a TNC could be useful.
What I find disappointing is that a TNC does not allow you to run your
own small application, instead of or in addition to the ones the firmware
designer has thought of. That would enable the use of a TNC for newly
developed applications without the constant upgrading of firmware.
It would be nice to download a (somewhat clever) APRS application and
then attach a GPS receiver instead of the terminal. Or a weather
station.
Or write your own application for other telemetry or telecommand purposes,
where the RS232 port of the TNC is connected to a given device with
given protocol, and a small application is needed to talk to the device
and use a sensible interface over the packet link.
Not very difficult, but astonsishingly enough: not available. I have
discussed it here in the past, and maybe I'll create something. But
it always has to be more primitive than it could have been, because I
will have to start from things like openly available KISS firmware,
not the usual TNC2 firmware which is not open.
charlesb
<luc...@eternal-flames.gov> wrote in message
news:1p9bpucj2ultgp4ie...@4ax.com...
For my part, I based my soundcard packet system in an old 486 PC system. The
whole deal, monitor and all cost 45 bucks or so, and it already had a
soundcard.
This system ran continuously, leaving my personal PC free for other things
at all times. The 486 would run terminal software, BBS software, a cluster,
whatever.
Charles, N5PVL
Steve, K5OKC
>
> Hmm, I still have that project of downloading an application into a TNC,
> still amazed that this does not exist yet.
It's called a ROM emulator. You remove the ROM and plug in a harness
that goes to a board, that then plugs into the parallel port. I have one
around here somewhere :-) You move the development software into
the boards RAM, and then the board simulates being a ROM.
Steve, K5OKC
>
> The posting I responded to was suggesting that a saound-card based
> system was as good as a TNC based system. It plainly is not. With
> the latter you can leave the TNC (and radio) running, without an
> additional computer and still enjoy the benefit(?) of a mailbox.
A minor distinction at best.
The point I was making, was that building a TNC from parts, is
more expensive than building a PC from parts. There are PC's
that will fit in the same size of a TNC-2 modem, that are much
more powerful than a Z-80 chip. Not only that, you can leave
it on all the time, and consume less energy than a TNC.
Rob Janssen
No, that is not what I mean.
What I intend to describe is a feature in a TNC to download a small
application image into the battery-backed RAM. This application can
call a couple of API functions to access the serial port and the
usual functionality of the TNC.
With a ROM emulator you would have to write a full firmware for the TNC
that drives the hardware.
Paul Keinanen
wrote:
>What I intend to describe is a feature in a TNC to download a small
>application image into the battery-backed RAM. This application can
>call a couple of API functions to access the serial port and the
>usual functionality of the TNC.
So the TNC should contain a Java virtual machine or Basic interpreter?
Paul OH3LWR
luc...@eternal-flames.gov
wrote:
>What I find disappointing is that a TNC does not allow you to run your
>own small application, instead of or in addition to the ones the firmware
>designer has thought of. That would enable the use of a TNC for newly
>developed applications without the constant upgrading of firmware.
You would think one of the manufacturers would have done that by now.
I suppose the downturn in packet activity has put them off.
>Not very difficult, but astonsishingly enough: not available. I have
>discussed it here in the past, and maybe I'll create something. But
>it always has to be more primitive than it could have been, because I
>will have to start from things like openly available KISS firmware,
>not the usual TNC2 firmware which is not open.
You could do a home-brew version. If it's only for your own use, you
could just swap the firmware EPROM/ROM for a larger one - if needed
(?) the firmware ROMs I've looked at have a lot of leftover unused
space already in them.
Then, just put the original code (suitably modified) back in, together
with your own additional code.
Using a larger ROM might mean playing with the addressing and of
course you would have to fully disassemble the original firmware
before you could modify it and add your own. It could turn into a
real dog to debug. :-(
Makes using a sound-card sound almost attractive. ;-)
Nick.
luc...@eternal-flames.gov
wrote:
>For my part, I based my soundcard packet system in an old 486 PC system. The
>whole deal, monitor and all cost 45 bucks or so, and it already had a
>soundcard.
$45 for a 486!!! You were robbed! :-)
I used to run a DX4 with two tnc's 70cms and 2M for a smallish
net-node. Worked fine.
73 - Nick.
Rob Janssen
That is probably not realistic. The application should be written
in Z-80 assembler.
luc...@eternal-flames.gov
wrote:
>No, that is not what I mean.
>
>What I intend to describe is a feature in a TNC to download a small
>application image into the battery-backed RAM. This application can
>call a couple of API functions to access the serial port and the
>usual functionality of the TNC.
>
>With a ROM emulator you would have to write a full firmware for the TNC
>that drives the hardware.
Ah! Ignore last posting. I also misunderstood what you were wanting
to do.
Mea culpa.
Nick.
Steve, K5OKC
>
> > So the TNC should contain a Java virtual machine or Basic interpreter?
>
> That is probably not realistic. The application should be written
> in Z-80 assembler.
Z-80?? Maybe use the CP/M emulator in Linux :-)
Here's what you need:
http://www.ibutton.com/TINI/hardware/index.html
The DS-TINI-1 is a compact (31.8 mm x 102.9 mm) 72-pin SIMM board. It is an
Ethernet-ready hardware implementation and supports all of the following features:
Hosts the TINI runtime environment in a validated hardware design
10 Base-T Ethernet for networking
Extensive I/O capabilities of the DS80C390 microcontroller exposed through JavaT APIs
Dual serial ports
Dual 1-Wire® net interfaces
Dual CAN (Controller Area Network) controllers
2-wire synchronous serial bus
General-purpose digital I/O
Easy system expansion using parallel bus interface
Real-time clock for time stamping
Flash ROM for storage and execution of runtime environment
512K/1 Mbyte nonvolitile SRAM provides fast, unlimited write operations and persistent data storage
Level translator provides RS232 voltages
Wide operating temperature range, -20°C to +70°C
Requires only a single +5V power supply
Malcolm Hopkins
>It would be nice to download a (somewhat clever) APRS application and
>then attach a GPS receiver instead of the terminal. Or a weather
>station.
Hi Rob,
I have a PacComm DFM TNC and it has a GPS feature as part of its
firmware. You use the terminal to set it up in GPS mode, issue the GPS
"on" command then unplug the terminal (RS232) and plug in your GPS. It
then transmits your position data, and an optional beacon message ( I
use the message to let people know about the PMS facility), at
whatever Beacon rate you have selected. That great thing about this
TNC is that whilst it is running in GPS mode, people can still connect
to its PMS and leave a message, all whilst you are mobile. Of course
you cannot read the messages until to reconnect your terminal, the STA
LED flashes to let you know you have a message. I usually leave a
bulletin in the PMS when I am mobile, to let anyone who connects to
know what I am doing.
I have no connection with PacComm but just think this particular TNC
is a great product. I use it in conjunction with a PacComm PSK-1 for
fullduplex satellite work, at least I used to until the 1200baud
microsats died, may have ago at 9600baud ones sometime.
Of course now one can buy a TinyTrak for mobile GPS use, but it does
not have the mobile PMS ability.
Regards
Malcolm ZL2THM
Malcolm Hopkins
Wellington
New Zealand
Please remove "no.junk.mail" from address to reply
charlesb
<luc...@eternal-flames.gov> wrote in message
news:fsrbpuob36dklk56o...@4ax.com...
> On Sat, 28 Sep 2002 14:13:53 GMT, "charlesb" <n5...@sbcglobal.net>
> wrote:
>
> >For my part, I based my soundcard packet system in an old 486 PC system.
The
> >whole deal, monitor and all cost 45 bucks or so, and it already had a
> >soundcard.
>
> $45 for a 486!!! You were robbed! :-)
>
That was about five years ago.
Charles, N5PVL
ham...@cloud.net.au
> On 28 Sep 2002 13:47:26 GMT, nom...@pe1chl.ampr.org (Rob Janssen)
> wrote:
>>What I find disappointing is that a TNC does not allow you to run your
>>own small application, instead of or in addition to the ones the firmware
>>designer has thought of. That would enable the use of a TNC for newly
>>developed applications without the constant upgrading of firmware.
>
> You would think one of the manufacturers would have done that by now.
> I suppose the downturn in packet activity has put them off.
There's an article by Mike Marcus N3JMM about software defined radio in
October 2002 QST. He suggests that manufacturers of commercial radios
which include DSP should allow much more user-reprogrammability of the
radio. However he concludes that one of the reasons they don't do this
is the user support aspects. The same would apply to user-programmable
TNCs.
The TNC2 is reprogrammable but you can't get the source code to the
latest release. In effect you would have to start from scratch.
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Rob Janssen
> luc...@eternal-flames.gov wrote:
>> On 28 Sep 2002 13:47:26 GMT, nom...@pe1chl.ampr.org (Rob Janssen)
>> wrote:
>>>What I find disappointing is that a TNC does not allow you to run your
>>>own small application, instead of or in addition to the ones the firmware
>>>designer has thought of. That would enable the use of a TNC for newly
>>>developed applications without the constant upgrading of firmware.
>> You would think one of the manufacturers would have done that by now.
>> I suppose the downturn in packet activity has put them off.
> There's an article by Mike Marcus N3JMM about software defined radio in
> October 2002 QST. He suggests that manufacturers of commercial radios
> which include DSP should allow much more user-reprogrammability of the
> radio. However he concludes that one of the reasons they don't do this
> is the user support aspects. The same would apply to user-programmable
> TNCs.
Yes, that is a problem. If I estimate the complexity of the problem well,
it will be much more work to write a document describing the available
API functions and the environment in which the application will operate,
than to actually implement the download functionality.
> The TNC2 is reprogrammable but you can't get the source code to the
> latest release. In effect you would have to start from scratch.
Or from the available KISS-mode sources. But that will mean the API
will only be "send and receive HDLC frame" and any connected-mode
functionality (the AX.25 protocol) will have to be provided by the
application.
Harvey Babb
Rob,
If you're serious about this, you might look at the firmware for the
TNC-1, which IS freely available and should be fairly easy to modify for
use on TNC-2 hardware. Sounds like something I'd have loved to have a
few years back! (Before I got too old/lazy ;)
73,
Harvey
WB5MCT
ham...@cloud.net.au
> ham...@cloud.net.au <ham...@cloud.net.au> wrote:
>> There's an article by Mike Marcus N3JMM about software defined radio in
>> October 2002 QST. He suggests that manufacturers of commercial radios
>> which include DSP should allow much more user-reprogrammability of the
>> radio. However he concludes that one of the reasons they don't do this
>> is the user support aspects. The same would apply to user-programmable
>> TNCs.
>
> Yes, that is a problem. If I estimate the complexity of the problem well,
> it will be much more work to write a document describing the available
> API functions and the environment in which the application will operate,
> than to actually implement the download functionality.
That sounds about right. Alternatively, the vendor could release their
code with little documentation and say "use the source, Luke." Keen
developers could work out the API.
> Or from the available KISS-mode sources. But that will mean the API
> will only be "send and receive HDLC frame" and any connected-mode
> functionality (the AX.25 protocol) will have to be provided by the
> application.
There are lots of recent TNC applications which don't involve a host
computer though (APRS). Still, it must be possible - there's a
relatively new APRS-specific digipeater called UIDIGI that is a new ROM
for the TNC2.
Rob Janssen
> Rob Janssen <nom...@pe1chl.ampr.org> wrote:
>> ham...@cloud.net.au <ham...@cloud.net.au> wrote:
>>> There's an article by Mike Marcus N3JMM about software defined radio in
>>> October 2002 QST. He suggests that manufacturers of commercial radios
>>> which include DSP should allow much more user-reprogrammability of the
>>> radio. However he concludes that one of the reasons they don't do this
>>> is the user support aspects. The same would apply to user-programmable
>>> TNCs.
>> Yes, that is a problem. If I estimate the complexity of the problem well,
>> it will be much more work to write a document describing the available
>> API functions and the environment in which the application will operate,
>> than to actually implement the download functionality.
> That sounds about right. Alternatively, the vendor could release their
> code with little documentation and say "use the source, Luke." Keen
> developers could work out the API.
I understand that the writer of the TNC2 firmware cannot release the source
due to contractual obligations.
>> Or from the available KISS-mode sources. But that will mean the API
>> will only be "send and receive HDLC frame" and any connected-mode
>> functionality (the AX.25 protocol) will have to be provided by the
>> application.
> There are lots of recent TNC applications which don't involve a host
> computer though (APRS). Still, it must be possible - there's a
> relatively new APRS-specific digipeater called UIDIGI that is a new ROM
> for the TNC2.
Of course that is possible. But that alternative ROM has to support
everything from the hardware up. Possible, but it would be more attractive
to write only the application, not the AX.25 stuff.
(for a digipeater this would probably only be possible with the KISS based
firmware anyway. but for a simple telecommanding/telemetry application it
would be attractive to have the normal TNC firmware available)
ham...@cloud.net.au
> I understand that the writer of the TNC2 firmware cannot release the source
> due to contractual obligations.
So I've heard. Surely as time goes on, this can be reviewed.
Steve, K5OKC
don't need the source to any of the original ancient
crap.
No one is going to run a PBBS anymore, and all
that other overhead code to support it is pretty much
worthless today.
Why would you want it? There's plenty of sound card
modems available, that I cannot fathom someone wiring
up a Z-80 or clone.
QFSK is the way to go for low baud rates, and those
modems are on a chip, or interface the sound card.
I wish TAPR would have dropped the spread spectrum
project when they sold-out to Dandin, instead of waiting
another two years to junk it. Maybe could have invested
the CPU board in being connected to a nice QFSK modem.
Ah well...
<ham...@cloud.net.au> wrote
charlesb
"Steve, K5OKC" <k5...@nojunk.cox.net> wrote in message
news:4LNn9.17709$nh2....@news1.central.cox.net...
>
>
> I wish TAPR would have dropped the spread spectrum
> project when they sold-out to Dandin, instead of waiting
> another two years to junk it.
I can't say I'm surprised to hear that TAPR is dropping the Spread-Spectrum
project.
After all those years of hype, all those "seminars" and "conferences", all
those magazine articles and so on...
Ever hear the story about "The Boy Who Cried Wolf" ? After a while,
everybody knew better than to pay attention to him.
Charles, N5PVL
Dana H. Myers
> Rob Janssen <nom...@pe1chl.ampr.org> wrote:
>
>>I understand that the writer of the TNC2 firmware cannot release the source
>>due to contractual obligations.
>
> So I've heard. Surely as time goes on, this can be reviewed.
Frankly, if someone was really interested, it would make
sense to start over. Yup, start over. Build an open-source
toolkit, initially concentrate on supporting the low-level
functionality and providing an implementation with APIs
to manage the HDLC transceiver, manage a buffer pool,
manage the host link. The initial release would provide
host-mode (KISS, most likely) functionality.
But, I question how much interest there really is...
Dana K6JQ
k6...@arrl.net
Steve, K5OKC
>
> Frankly, if someone was really interested, it would make
> sense to start over.
Yes, the Z-80 code will have very little value as a reference.
It's been reverse engineered several times, and nothing good
became of it.
> Yup, start over. Build an open-source toolkit, initially
> concentrate on supporting the low-level functionality and
> providing an implementation with APIs to manage the
> HDLC transceiver
I would hope that HDLC would not resurge. It's been an
interesting exercise, I enjoyed packet in the late 80's, but to
continue on is not within the spirit of developing something
more advanced for radio.
The FEC stuff from NASA, or the block coding techniques,
etc, would be much more useful to experiment with, at both
the hardware and software levels.
> But, I question how much interest there really is...
True. A good question.
Rob Janssen
> ham...@cloud.net.au wrote:
>> Rob Janssen <nom...@pe1chl.ampr.org> wrote:
>>>I understand that the writer of the TNC2 firmware cannot release the source
>>>due to contractual obligations.
>> So I've heard. Surely as time goes on, this can be reviewed.
But not yet, apparently.
> Frankly, if someone was really interested, it would make
> sense to start over. Yup, start over. Build an open-source
> toolkit, initially concentrate on supporting the low-level
> functionality and providing an implementation with APIs
> to manage the HDLC transceiver, manage a buffer pool,
> manage the host link. The initial release would provide
> host-mode (KISS, most likely) functionality.
An "open source" TNC2 firmware exists, but it is written in C and
it is primarily focussing on hostmode. The compilation environment
may be difficult to reproduce. Maybe it is away to approach things...
Dana Myers K6JQ
> "Dana H. Myers" <k6...@pvbb.net> wrote
>>Yup, start over. Build an open-source toolkit, initially
>>concentrate on supporting the low-level functionality and
>>providing an implementation with APIs to manage the
>>HDLC transceiver
>
>
> I would hope that HDLC would not resurge. It's been an
> interesting exercise, I enjoyed packet in the late 80's, but to
> continue on is not within the spirit of developing something
> more advanced for radio.
Fair enough. I suppose what I really meant to say, the toolkit
would have to provide support for the serial controller in all
of the interesting modes. The overwhelming legacy requirement
is HDLC/AX.25, but that doesn't preclude other modes. That's the
reason for the open-source toolkit approach.
> The FEC stuff from NASA, or the block coding techniques,
> etc, would be much more useful to experiment with, at both
> the hardware and software levels.
Indeed, you're right.
>>But, I question how much interest there really is...
>
> True. A good question.
I know for one I'm not inclined at this point to
run off and take on this project.
Dana K6JQ
k6...@arrl.net
John Ackermann N8UR
>Rob Janssen <nom...@pe1chl.ampr.org> wrote:
>> I understand that the writer of the TNC2 firmware cannot release the source
>> due to contractual obligations.
>
>So I've heard. Surely as time goes on, this can be reviewed.
>
>Hamish
Just to clarify, the TNC-2 code was written by an individual who graciously
made it available in object-code form to TAPR, and through TAPR to licensed
TNC-2 OEM manufacturers and end-users, for ham use. However, he also uses
this code base for derivative products sold into the commercial (non-ham)
market for real money. Because of this ongoing use, he's chosen not to
release the source code.
73,
John N8UR
j...@febo.com -- n8...@tapr.org
B. Smith
>
> Just to clarify, the TNC-2 code was written by an individual who
graciously
> made it available in object-code form to TAPR, and through TAPR to
licensed
> TNC-2 OEM manufacturers and end-users, for ham use. However, he also uses
> this code base for derivative products sold into the commercial (non-ham)
> market for real money. Because of this ongoing use, he's chosen not to
> release the source code.
There's enough TNC-2 source code out there, that this is a non-issue.
If we could just shift into second gear, is the problem. What comes after
AX.25 in VHF and UHF? Are we to bit-shift callsigns forever :-)