[App_rpt-users] Ardunio PLL Programming of GE MVS

Benjamin Naber Benjamin at Project23D.com
Thu Jan 11 04:20:19 UTC 2018


The idea for this project is aimed to be, along with many other uses,
to enable programming of otherwise non-front-panel-programmable radios
with existing repeater controllers using DTMF.

Also, there are more than just Maxtracs, and GM300 that could be used
with this code. Presently, any radio with a PLL that follows the data
type set of the MC145158 or MC145159, can be used. The code will then
be allowed to branch out to other PLLs enabling the list of radios to
grow. 

It will then be possible, with some hardware mods, to turn an old
analog bag phone into a 900MHz repeater. That's another project in the
works, haha. I've already figured out how the RF sections of the Nokia
made Radio Shack branded bag phones work.

Front panel programmable radios, should be in cars and home stations,
not at repeater sites, for a multitude of reasons.

The code for the GE MVS is here. I'm learning about git, so there will
be some bumps a long the way. So, you may have to do some digging
around my account.

https://github.com/Project23D/Arduino-Radio-Control/blob/Motorola-VHF/U
HF-MC145158/GE-MVS_PLL-control.ino

as soon as I figure out git, I'll upload the original code published,
plus the Maxtrac PLL variation... As well as other code variations.

~Benjamin, KB9LFZ


On Tue, 2018-01-09 at 22:56 -0600, Benjamin Naber wrote:
> For those of you who are knowledgeable in the code of Arduino:
> 
> I've begun a project that I jumped into the the *very* deep end,
> while
> knowing just barely how to swim.
> 
> I've managed to get the radio to tune to a frequency that I want, but
> very flaky at best when it comes to tuning well within the limits of
> thr VCO; the arduino freezes every now and then, and quite frankly I
> am
> not working with (cough, not understanding), the existing code.
> 
> In a nutshell, what I am doing is breaking the MC145159 control lines
> from the GE MVS CPU, and soldering in a few wires, plus a ground, to
> the base pins of the transistors that ulitamtely lead to the CLK,ENB,
> and DATA pins of the PLL.
> 
> The reason why I am doing this is to enable free tuning of the radio
> without the need to program the radio using normal computer
> programming
> methods, ie, a cable, and a special program that is hard to come by,
> as
> well as must run this program on older hardware
> 
> Given that Arduinos can be programmed from just about anything, this
> enabled on the fly on at least, on site programming of the radio. I
> am
> working towards enabling the use of these radios, and a couple others
> to be controlled by repeater controllers, and allstarlink nodes using
> kenwood data command set. Or whatever it is.
> 
> Boiled down, this will enable good, inexpensive priced commercial
> radios to continue life; anyone who knows how to solder and program
> an
> Arduino can now use a commercial for a repeater VHF/UHF remote base,
> Allstarlink, IRLP, Echostink node radio, scanner, whatever.
> 
> With the significantly better RX fronts ends on these radios, cleaner
> TX, these will significantly outperform any chinese radio attached to
> any RoIP node.
> 
> 
> ---------
> Here is where I am stuck:
> 
> The MC145159 PLL wants the tuning data sent as follows:
> 14 bits for R counter
> 10 bits for N counter
> 7 bits for A counter
> 1 high bit for control.
> 
> Totaling 32 bits. The current code, posted immediately below does not
> seem to allow this:
> 
> 
>    emit_byte (0x14);
>    emit_byte (0x01);
> /* Send "(n << 8)|(a << 1)", 24 bits, MSB first, LSB always zero */
>   //emit_byte (n >> 2);
>   emit_byte ((n >> 8 ) & 0xFF);  /* N high byte */
>   emit_byte (n & 0xFF);   /* N low byte */
>   //emit_byte (a & 0b1);   // send only seven bits?
>   emit_byte (a << 1);   /* A and LSB 0 */
>   //emit_byte (0x01 << 7);        // send only one HIGH bit?
>   
>   pulse_le();     /* Latch it */
> 
> the "//" are my futile attempts to work around this, and leave
> commented out so I know what I *think* did not work.
> 
> I've also the following to form the four bytes being sent, MSB of
> each
> counter first, control bit last:
> 
> emit_byte ((r) & 0xFF);  /* send first eight bits of r counter*/
> emit_byte (((r & 0xFF) & n) & 0xFF);	/* send last 6 bits of r
> counter, then send first two bits of n counter */
>   
> emit_byte ((n & 0xFF) & 0xFF);	/* send last eight bits of n
> counter */
> emit_byte (((a) & 0xFF) & 0x01 << 7); 	/* send seven bits for
> a
> counter, and one HIGH bit for control bit */
> 
> 
> What does work now to test to make sure this project is even
> feasible:
> 
> in the void setup() section
> 
> ....
>   emit_byte (0b00101000);  // first eight bits of R counter
>   emit_byte (0b00000001);  // last 6 bits of R counter, first two
> bits
> of N counter 
>   
>   emit_byte (0b00110011);  // last eight bits of N counter
>   emit_byte (0b10001001);  // 7 bits for A counter, last control bit
>   pulse_le();
> 
> .......
> 
> the above test code does work to successfully set the radio to 5 KHz
> step, and program the N + A counters to 151.820MHz + 45MHz
> 
> 
> 
> 
> Sorry it was long, However the more info you have to see what is
> going
> on, the less guessing you have to do.
> 
> ~Benjamin, KB9LFZ
> _______________________________________________
> App_rpt-users mailing list
> App_rpt-users at lists.allstarlink.org
> http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
> 
> To unsubscribe from this list please visit http://lists.allstarlink.o
> rg/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the
> bottom of the page. Enter your email address and press the
> "Unsubscribe or edit options button"
> You do not need a password to unsubscribe, you can do it via email
> confirmation. If you have trouble unsubscribing, please send a
> message to the list detailing the problem. 



More information about the App_rpt-users mailing list