Reworking an old FM radio to 2.4GHz er9x

Retro radio updates, hacking and mods
User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Sat Jul 25, 2015 3:12 pm

Have you changed myeeprom.h at all?

To handle calibration of these extra inputs, you need to have some extra calibration values, but you can't extend the existing arrays in "struct t_EEGeneral" as doing so will upset all the other values that follow in the structure.

As a first step I would suggest not calibrating them at all, and at the beginning of:
int16_t scaleAnalog( int16_t v, uint8_t channel )

Code: Select all

add:
  if (channel > 6 )
  {
    return v ;
  }
This will just use the raw analog values.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!


ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Mon Jul 27, 2015 5:57 pm

Yes, I really had added one byte as setup of a glidepath that defines the zero line for sinking and climbing.
But as for this radio, I will never implement telemetry, I removed it and so far, eePe and er9x are now compatible again. That means, I can download an eeprom to the PC, modify it and restore it to the radio.

adding the "raw data" suggestion for the sliders did not work. I also tried to force the value of a single slider for every call of the routine by setting if (channel>6) return s_anaFilt[8], but also no success.

But I just discovered something worse and that failure exists since I merged the modifications from the ersky9x code. (verified it on an intermediate backup that I took at that time).

When I set up a simple model, but change the sources to something like P1,P2,P3,CH1 for the first four channels, after waiting a minute and then power off/on, the four channels have RUD,ELE,THR,AIL as sources, according to the channel order.
If I do the same for any of the higher channels, their mix is simply lost.

But If e.g. I add a switch or another parameter to such a channel, then this channel is not lost.

Maybe it's better to restart from the beginning (merging the modifications).

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Tue Jul 28, 2015 1:03 pm

Ok, I started from the beginning, with a fresh copy of my version of r818. I removed the modification that added one byte into the EEGeneral structure as that was only needed for telemetry, that I will not use on this radio. A final modification has been left in so far as I use one spare bit of the last byte of EEGeneral

I implemented everything from ersky9x r217 (from ersky9x.cpp and menus.cpp) that is contained between the #ifdef NUM_EXTRA_POTS and #endif and added some defines in er9x.h


In menus.cpp I also added this line following ====Swash Ring ==== with:
for (uint8_t i=0; i<7+NUM_EXTRA_POTS;i +=1;)
as I assume, it should be there.

In menuProcSwitches(...) at
Case 1:
switch (cstate)
case (CS_VCOMP):
case (CS_VOFS) :
in ersky9x there follow several expressions like cs.v1 and cs.v2 that gave compile errors.
I changed them to cs->v1 and cs->v2, hoping that that would be ok (as I really don't understand these constructs).

After having cleaned up all compile errors that I had introduced, it looked good.

pro:
In the DIAGANA menu I can see my working slider values.
When I edit a mixer line, I have the new sliders available following the pots.

cons:
When I add one (ore more) mixerlines (only setting a source and touching no other parameter e.g. ch6 = 100% P1) to a channel above channel4, wait some time before I power Off/On the radio, these
mixes are lost.
If I add a switch to it ( ch6=100% P1 sw(THR)) the mix remains over a power off/on .

If I add a channel that has any of the new sliders as source, nothing (or nothing useful) is displayed in the system menus. Modifying "scaleAnalog()" to return unscaled "v" (or s_anaFilt[9] or return 1000) doesn't display something different.

That my status in the moment, so further help required.

Reinhard

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Tue Jul 28, 2015 3:06 pm

In perout()
change:

Code: Select all

            else
						{
							v = calc_scaler( k - (MIX_3POS+MAX_GVARS+1), 0, 0 ) ;
						}
to:

Code: Select all

            else if (k > MIX_3POS+MAX_GVARS + NUM_SCALERS)
						{
							// ( k >= EXTRA_POTS_START )
							// An extra pot
							v = calibratedStick[k-EXTRA_POTS_START+8] ;
						}
            else
						{
							v = calc_scaler( k - (MIX_3POS+MAX_GVARS+1), 0, 0 ) ;
						}
to pick up the new sliders values as source.

When inserting a mix, there is a commented out "STORE_MODELVARS" in the insertmix function, try removing the //.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Tue Jul 28, 2015 11:08 pm

Added the code. Seemed to do nothing.
Uncommented the "STORE_MODELVARS" and now the mixes are stored AND I get slider values displayed.
Adressing of the channels is shifted by one position and the range is rather small.
I still return from "scaleAnalog()" with
if (channel > 6) return v;

I changed that to ... return s_anaFilt(channel+1);
This way, the channels are correctly adressed, but vary only from +100 to +60 on one half of the slider.

... return (s_anaFilt[channel+1] -1000);
moves the range to the middle of the slider way (+- 30).

... return ((s_anaFilt[channel+1] << 1) + s_anaFilt[channel+1]) -3072 ;
expands the range to nearly -95 to +100 with small differences between the different slider channels.

Using the sliders in the mixes works so far :D


The sliders up to now show up in the source field of the mixes (that does work now) and additionally in the source field of the voice switches. But there, again no value ("0")is displayed and the adressing of the sliders also seems to be offset by one channel as for the last slider the value is displayed as "0.0A".

Thanks Mike for helping me so far. I hope I didn't bother you to much.

Reinhard


User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Tue Jul 28, 2015 11:39 pm

Check the function:
int16_t getValue(uint8_t i)
in er9x.cpp. The version in ersky9x has code for picking up the "EXTRA_POTS" value.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Wed Jul 29, 2015 2:41 pm

sliders show their values now in the voice editor :D

But the last slider gets unit "A" and one decimal position displayed.

As far as I got, the "menuProcVoiceOne()" calls the
"putsTelemetryChannel (12*FW,FH,pvad->source-CHOUT_BASE-NUMCHNOUT-1,value,0,TELEM_UNIT)"

and there the unit for slider4 gets added. But I don't get it to supress the units of slider4. When the unit is suppressed, they are shifted by severeal positions on the higher sources.

Reinhard

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Wed Jul 29, 2015 3:14 pm

In menuProcVoiceOne() you heve:

Code: Select all

      if (pvad->source > CHOUT_BASE+NUM_CHNOUT)
 			{
				putsTelemetryChannel( 12*FW, FH, pvad->source-CHOUT_BASE-NUM_CHNOUT-1, value, 0, /*TELEM_NOTIME_UNIT |*/ TELEM_UNIT ) ;
			}
			else
			{
				lcd_outdez( 12*FW, FH, value ) ;
			}
the first line probably needs to be:
if ( (pvad->source > CHOUT_BASE+NUM_CHNOUT) && ( pvad->source < EXTRA_POTS_START ) )
so the value is just displayed as decimal, not as a telemetry value. I think I'll need to do this change to ersky9x as well!

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Wed Jul 29, 2015 5:09 pm

That's working now.
All four slider values are now ok. No more "A" behind the last.

But the same change must be done for the "Value" field, as it also displays the "A".

Question:
For "Full" as source, the value displayed is 0. Shouldn't that be 100 ?

For Source "Timer 1/2" the timer value in the "Value" line should be positioned some characters to the left, because the last characters wrap into the next line.

Thanks.

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Wed Jul 29, 2015 5:47 pm

one option to move the timer values one character to the left is in
putsTelemetryChannel()
case TIMER1 :
case TIMER2 :
....
change "putsTime(x-FW,y ......"
to "putsTime(x-2*FW,y,......."

Both values and the timer number following the value are now correctly displayed.

On the other hand, is it really neccessary to have the number of the timer following its value, as the selcted timer is clearly identified in the source field (Tim1 / Tim2) ?

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Thu Jul 30, 2015 1:14 pm

Now , as the software more or less does what I need, I'm now facing a much more severe problem at the receiver side. :cry:
(I tested with a 3 channel receiver, so only 3 servos max used)

The servos, that are driven from a slider don't stay calm but are really noisy.

They jump in a timely random manner around three times per second into the shorter puls direction (The end of the servo horn moves about 2mm, sometimes even more).
with rare exceptions, all three servos jump at the same time. I would say at 90% of the time, all three servos jump at the same time and now and then anyone of the three makes either an extra cycle or misses one.

On the system screens and in DIAGANA menu, Channel bar and/or number displays do not show any recognizable variations.

Servos driven by the pots that are connected to the identical voltages (+5v and ground) as the sliders, stay absolutely calm at the same time.

When I hardcoded a fix analog value for all the channels (instead of measuring) the servos stayed still, no noise.

I permanently have added capacitors (0.1uF) to the slider signal wires (= inputs to the multiplexer).
I tried several delays between selection of the multiplexer and analog measuring
I tried (up to 10) dummy measuring cycles before the actual conversion cycles
I added/removed switching the selection lines of the multiplexer from outputs to "inputs with pullups" at the end of the routine

None of the above changed the behaviour in a recognizable manner.

Reinhard

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Thu Jul 30, 2015 1:23 pm

Do you have an oscilloscope, or could borrow one, to be able to look at the pulses?

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Thu Jul 30, 2015 10:15 pm

Yes. I have.
The selecting signal(s) is not really stabel. The duration of the selection pulses varies randomly. Could be similar to the rythm of the noise on the servos.
Displaying/synchronizing on a selection signal and on the other channel the analog output of the multiplexer, whenever the pulses jump, the analog output also jumps and overlays the non-jumping part. So you never can see if the output voltage is stable or if the was a break-in in the voltage.
I'll try to make some pictures.

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Fri Jul 31, 2015 9:00 am

I probably detected the reason of the noise.

I made a version that, in getadc_Osmp() counts the "additional sliders" selection code only up to 8. The code to select the sliders is run only once and selects slider1. (The mask that is ored to the port is 6<<1 that should be 0x40 or Bit6)

Problem is still there.

I basically had expected to see the selection pulse on input A of the multiplexer, but it is on B. (I triggered on the input B of the multiplexer and most of the time I get a selection pulse of 115usec but it randomly varies up to 195 usec.

But when I displayed selection input C of the multiplexed, I got an additional pulse at a repetition rate of around 100msec that selects slider4 !!

And thats obviously the problem.

When I setup both sliders (1 & 4) to the same value, the noise disappears.

Now the question is, who is creating this extra pulse ?
If that has something to do with telemetry, It's no problem to kill it, as this radio will not use telemetry.

Reinhard

edit:
Its correct to see the first slider select signal on input B of the multiplexor

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Fri Jul 31, 2015 11:19 am

I just found, that the LCD communication is running over PORTC.

And the code contains heavy usage of all bits of Portc. But I don't understand if that is only the case for using a serial LCD or if it also happens with the standard parallel LCD.

If it is to much effort or not possible to suppress the other usage of Bit7 of portC, I could rewire the sliders to use inputs 4 to 7. This way input C of the multiplexer had always to be high. I hope in this case, the high other pulse would do no harm to the slider values.

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Fri Jul 31, 2015 3:30 pm

Using the hi channels of the multiplexer seems not to work.
I tried with fix slider4, that uses only inputC of the multiplexor and the noise is still there.

I add some pictures. The upper channel is the output of the multiplexor and the lower channel is the selection signal of input C.
100_1950.JPG
Selection pulses and mixer output of same length
100_1951.JPG
some selection pulses longer than the mixer output
100_1956.JPG
some mixer outputs longer than the selection pulses

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Fri Jul 31, 2015 4:09 pm

These pictures are with slider 1 selected as the only channel. It shows in the uper trace the input C of the multiplexer and in the lower channel the input B

As only slider1 is selected, there should not be any signal on multiplexer input C.

InputC shows pulses on the left and right edge of the screen 100msec apart (+-5msec).
InputB shows two pulses every 10 msec (synchronized with inputC)

100_1959.JPG
100_1957.JPG
synchronized with inputB of the mixer. Shows one pulse on inputC. not stable but crossing the screen unsynchronously.
100_1962.JPG
Reinhard

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Fri Jul 31, 2015 10:48 pm

I can't see anything that should be affecting these signals on PORT C. The LCD code ends up using SBI and CBI instructions that only modify single bits. Differing pulse lengths are probably caused by an interrupt occuring. There is some code in frsky.cpp that modifies bits 6 and 7, but if "FRSKY MOD DONE" is off, this shouldn't be executed.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Fri Jul 31, 2015 11:03 pm

I already had removed the 'private data' handling in frsky.cpp but as you said, no data there to be handled, no reaction.

I have searched the code for PORTC statements and could nothing find that affects bit0 of Portc.
Could it be that there is another way of addressing this bit? e.g. via the register number ?

Reinhard

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Sat Aug 01, 2015 9:01 am

I've searched the listing file (.lss) and can't find any other references to PORTC by number.
Please post the multiplexor code you are using.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Sat Aug 01, 2015 11:18 am

It might be worth trying the standard er9x code, with just this line (at the start of main()):
DDRC = 0x3e; PORTC = 0xc1; //pullups nc
changed to:
DDRC = 0xFF; PORTC = 0xc1; //pullups nc
so PORT C is all outputs, and PC0,6,7 are all set high.

Then look at the signal on PC0 and see if it changes at all.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Sat Aug 01, 2015 12:49 pm

Thanks Mike for your help.

I has that changed already and in getADC_osmp() removed my instruction to set the required port bits to outputs.

I was searching a rather long way. I let getADC_osmp() return immediately without doing anything and the mysterious pulse on inputC was gone.
Then I tried to exit the routine after having read only one of the sliders and it worked, no stutter, no jumping on the servo on this single channel.

It looked like it had something how I set the port.
I then limited the adc-channel count to eleven (one channel less), and all the three channels were moving smoothly. :D

Finally i set it back to <12 and it still worked.

I compared my now working code with one that I saved as backup when I had the problem and I do not really see a difference.

But once again, it's working now. :mrgreen: :mrgreen:

Thanks again

Reinhard

ReSt
Posts: 1498
Joined: Tue Dec 27, 2011 11:34 pm
Country: -

Re: Reworking an old FM radio to 2.4GHz er9x

Post by ReSt » Sat Aug 01, 2015 2:50 pm

MikeB wrote:It might be worth trying the standard er9x code, with just this line (at the start of main()):
DDRC = 0x3e; PORTC = 0xc1; //pullups nc
changed to:
DDRC = 0xFF; PORTC = 0xc1; //pullups nc
so PORT C is all outputs, and PC0,6,7 are all set high.
Sorry, overlooked your previous post.

I also tried that and the levels were high most of the time.

Now I have set it to
DDRC=0x0ff;
PORTC=0x00;
intentionally made the outputs low so I see the switching signals easier when they go high.

Is the mixer code still of interest?

Reinhard

User avatar
MikeB
9x Developer
Posts: 16270
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset, UK

Re: Reworking an old FM radio to 2.4GHz er9x

Post by MikeB » Sat Aug 01, 2015 3:28 pm

Probably no need now, since it is working.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!


Post Reply

Return to “Retro Radios”