1200 baud regen

[Dennis Rosenauer]

I agree with using the Atmel AVR processors.  They work very well and 
are well supported by GCC.

I use them for embedded projects both at home and at work.  I have no 
longer any use for the PICs.

For the bit-regen.  I built a hardware unit for the 56K system long ago. 
  Basically it works like this:

The RX provides clock and data, we used a 32 bit deep fifo, I think it 
was a couple of 40105s.  When the RX carrier detect became active, turn 
on the TX, it will be seeing all 1's for a bit but that will give 
everyone some time to sync up.  The fifo was filled for the first 16 
bits (1/2 full) at that time the state machine enabled the TX data, it 
was clocked out at the TX clock rate which could be different than the 
RX.  This would give you what the telco's called an elastic store.  The 
incoming RX clock and the TX clock could differ and everything would be 
OK as long as the fifo never emptied for filled, if it did then the 
packet was corrupted and the CRC would fail.  When the fifo emptied at 
the end of the packet the TX would stay up for a few milliseconds to 
keep the receivers in sync.  It would be sending scrambled all 1's.  If 
the next packet came in it would start filling the fifo again and things 
would continue.

If you want to use this scheme for 1200, you have to extract the clock. 
  You will need a clock recovery PLL and an NRZI to NRZ decoder and a 
NRZ to NRZI encoder on the TX side.  It can be done fairly easily in 
software on a microcontroller.  I would do it with an AVR at 56K if I 
had to do it again.

There was a design kicking around for a digital PLL and carrier detect 
circuit for 1200 and faster packet years ago.  I have no idea if you can 
find it.  I designed a digital PLL for the 56K modem I did about 10 
years ago now.  I did it all with a few PALs and some random logic.

Dennis, AC7FT.


Curt, WE7U wrote:
> On Mon, 12 Oct 2009, Bill V WA7NWP wrote:
> 
>> It might be a good development environment for a pic regen.
> 
> I'm not a big fan of PIC's, but they are cheap and have done a good
> job of seeding the experimenters with programming systems and
> development environments.
> 
> If you want to go with Atmel AVR instead (much better processors),
> there are freebie Windows and Linux development environments.  You
> need an SDK board to get going with it.  Check out the AVR Butterfly
> for a low-end example that could get you going.  I have several SDK
> boards available to me but the Butterfly is not one of them.
> 
> I've done cross-compiling for PalmOS (68k), Atmel AVR, and 68HC11 on
> Linux, all with free tools.
> 
> I tend to help out on projects where I need zero or a minimum $$
> investment to get started.  That means open-source toolchains.
> If you wish to have help on future ham projects, don't require
> developers to buy tools.  I don't help out with Opentracker/Tracker2
> development even though the software is open-source, because the
> developer toolchains cost money.  There's no incentive for me to
> help out.  If the toolchains for those processors were free I'd be
> tempted to install them and make improvements/bug-fixes to the code.
> 
> Just stating some options.  Take 'em or leave 'em!
>