[arm-allstar] Ardunio PLL programming GE MVS

[WB4BXO]

Sorry, I meant shifted right 4 where I said 8 below....   rush day, CES is just about to open for the day.

Steve Mobley - WB4BXO

--- Hello, I am an iApp-oholic...


On Jan 10, 2018, at 11:47 AM, WB4BXO via arm-allstar <arm-allstar at hamvoip.org> wrote:

Hey Benjamin,
I'm slammed now until CES ends so I haven't looked extensively at what you are doing, but... keep in mind that the shift operators perform differently on signed and unsigned numbers. For instance a char type with a value of 0xC0 shifted right 8 places yields 0xFC but an unsigned char with a value of 0xC0 shifted right 8 yields a value of 0x0C. 
A few ways to deal with this... always mask to the bits you expect in the result or cast the values into an unsigned type before doing your shifting. For the later you could do something like write a macro to do your shifting irrespective of sign like this (not tested)...

#define SHIFT_LEFT(variable,bits) ((unsigned int)variable<<bits)
#define SHIFT_RIGHT(variable,bits) ((unsigned int)variable>>bits)

And actually the SHIFT_LEFT isn't needed, only right shifts are affected by sign, but to keep the code consistent might as well since it will have zero affect on run time.

You may then have to cast the results to the type of the target, depends on your usage and the strictness of the compiler you're using. Like:
emit_byte((unsigned char) SHIFT_RIGHT(someVar, 2));

I don't know off hand the details of the Arduino compiler, I usually use the GNU AVR compiler, so things may be different there, but maybe this will help.

Steve Mobley - WB4BXO

--- Hello, I am an iApp-oholic...


On Jan 9, 2018, at 11:59 PM, Benjamin Naber via arm-allstar <arm-allstar at hamvoip.org> 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 tried 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
_______________________________________________

arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar

Visit the BBB and RPi2/3 web page - http://hamvoip.org
_______________________________________________

arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar

Visit the BBB and RPi2/3 web page - http://hamvoip.org