openrcforums

Right chaps.. lets try keep all 'highly technical' chat to this thread. It will help end users avoid being bombed out by too much techy jargon!

I seem to recall that a while back, there was talk of using pin 43 on the MCU (via a suitable transistor/FET) to drive the vibrator motor. Has this ever been programmed up and released?

Flaps 30 wrote:I seem to recall that a while back, there was talk of using pin 43 on the MCU (via a suitable transistor/FET) to drive the vibrator motor. Has this ever been programmed up and released?

I have all the parts for this - and even the soldering done on my tx. Just not done the code yet.

I should have it working in the next couple of weeks - christmas been keeping me too busy

rob.thomson wrote:I have all the parts for this - and even the soldering done on my tx. Just not done the code yet. I should have it working in the next couple of weeks - christmas been keeping me too busy

You are at the same place as I am. Sadly I am not a coder type person. Of course I am also looking forward to any progress on meaningful 'bleeps' to go with the Winged Shadow Thermal Scout.

Most of this can wait until the warmer weather. I don't do cold these days.

Never fear.. will be done in a few weeks

rob.thomson wrote:Never fear.. will be done in a few weeks

Just re-read the original message and realised I missed the point.

Check: http://code.google.com/p/er9x/wiki/Spea ... rateHaptic

The Vibration Alert has been working for ages.

I thought when I skimmed your message that you meant the option to switch on and off two different tx modules from one of the other spare ports.

Rob

rob.thomson wrote:I thought when I skimmed your message that you meant the option to switch on and off two different tx modules from one of the other spare ports.

Ahh! ... Okay.. Yes. My enquiry concerned the use of pin 43 to drive the motor. I'm guessing the one you are talking about, is the possible use of the other spare pin, that is number 35.

I could suggest that the vibration motor drive might be selected for various functions. Like on the positive climb signal from the Thermal Scout. That would put a smile on my face.

. I and my colleagues on a hobby from Russia we thank all firmware developers and updatings for the big and good work.
Now I have an interest to sound updating of the transmitter Flysky from Frsky telemetry radio . I consider that it is very important and necessary option. Whether I can hope, what in the near future such updating will be accessible? It would be desirable, that for sound updating the inexpensive sound module with support мр3 files and compatible with telemetry Frsky was used. It would be very useful, if the transmitter a voice message warned about critical options on of an onboard voltages and the power battery, on radio signal level, on voltages of the transmitters battery, the flight timer. I think it not the complete list of possibilities of sound (voice) updating.
Excuse for my English.

Flaps 30 wrote:

rob.thomson wrote:I thought when I skimmed your message that you meant the option to switch on and off two different tx modules from one of the other spare ports.

Ahh! ... Okay.. Yes. My enquiry concerned the use of pin 43 to drive the motor. I'm guessing the one you are talking about, is the possible use of the other spare pin, that is number 35.

I could suggest that the vibration motor drive might be selected for various functions. Like on the positive climb signal from the Thermal Scout. That would put a smile on my face.

Yes. The function to make it 'vibrate' on a thermal is not in place yet - but due very soon. For now you get vibrations on alerts and trim centers etc

Rob


Sent from my iPhone using Tapatalk

Ok, we have a new forum.. now would be nice to have some PCM audio for the er9x

This looks good...now to get everyone over here !
Earl

uphiearl wrote:This looks good...now to get everyone over here !
Earl

I'm here,site really looks great Rob.
Tom

Hello, Rob! Many thanks for ER9! My friend and I figured out a bit with her and look forward to providing EEPROM for general use!

I'm new to this stuff. I just flashed my 9x and love what you have done so far. I have a question.. One of the other guys verions has added a SD card mod. Are you planning on doing that in the future?

Crash_Jim wrote:I'm new to this stuff. I just flashed my 9x and love what you have done so far. I have a question.. One of the other guys verions has added a SD card mod. Are you planning on doing that in the future?

Yes, actually already done sort of, check this topic for more info

hey guys hope someone can help me out here im trying to flash my radio witha new revision of er9x and for some reason now the aileron wont report as being on no matter what i do nothing has changed hardware wise so i looked at the code and i did see that someone changed how the pins were selected for the frsky mod version so i tried changing the pins as beest as i figure out and its still acting weird so i put up a issue on the er9x page about a weeks ago and still havent heard back

now i noticed in the code comments there is something about a test at bit 0 for pin 7 i couldnt find anything that referenced that in running code so i disregarded that.
could i have missed something and it is in running code?

Can you confirm the following please.
1. You are were and are running the FrSky version of er9x.
2. You have done the mod to move the two switches to other pins.
3. If you go to the main screen that shows THR RUD and ELE down the left and AIL GEA and TRN down the right all the other 5 switches show reverse video/normal video when you switch them and the AIL does not. Which state is the AIL in normal or reverse video?
4. If you put r347 back on then, on the same screen, all 6 switches operate correctly.

Mike.

yes to everything and the aileron is normal video as if it was off

That's Weird then. I've checked back to the source for r347 and it is working the same way. There is a code change I put in that saves some memory, but logically it operates the same way, and works for the throttle cut switch. If it is still working on r347, then the wiring must be OK and the switch is switching. It is working on my Tx. I shall have to give it some more thought, it should be OK.

Mike.

i dont use the default pins for the connections could that be it?
i believe i use c6 and g2

Mechcondrid wrote:i dont use the default pins for the connections could that be it?
i believe i use c6 and g2

The 'standard' FrSky build expects the moved switches to be on C6 and C7, so that is why your AIL switch is not working. Where did you get your r347 version from? It sounds like it was a 'special'.

Mike.

its the regular frsky version i recoded to use those pins it makes it easier to solder with my hands
and i did this with the 646 revision too but its not working right

Mechcondrid wrote:its the regular frsky version i recoded to use those pins it makes it easier to solder with my hands
and i did this with the 646 revision too but its not working right

In drivers.cpp is the line:
case SW_AileDR : xxx = PINC & (1<<INP_C_AileDR); //shad974: rerouted inputs to free up UART0
and in er9x.h:
#define INP_C_AileDR 7

These look for the AIL switch on PORTC bit 7. If yours is on PORTG bit 2, then I would expect
In drivers.cpp:
case SW_AileDR : xxx = PING & (1<<INP_G_AileDR); //shad974: rerouted inputs to free up UART0
and in er9x.h:
#define INP_G_AileDR 2
(Make sure you get G not C).

ALSO, in er9x.cpp, PORTG is configured with bit 2 set as an output to drive the HAPTIC motor for vibration alerts.
DDRG = 0x14; PORTG = 0xfB; //pullups + SIM_CTL=1 = phonejack = ppm_in, Haptic output and off (0)
and in audio.h
#define HAPTIC_ON PORTG |= (1<<2)
#define HAPTIC_OFF PORTG &= ~(1<<2)

I suggest you change the line in er9x.cpp to:
DDRG = 0x10; PORTG = 0xfF; //pullups + SIM_CTL=1 = phonejack = ppm_in, Haptic pin is input
and in audio.h:
#define HAPTIC_ON
#define HAPTIC_OFF

Most likely it is the HAPTIC output that is causing you a problem.

Mike.

yup that was it ; i was unaware that haptic had been merged into the frsky build thanks a bunch

Mike,

In companion9x when I import and compile er9x there is a warning which in my opinion could be solved:

It's in pers.cpp:50
strcpy_P(g_model.name,PSTR("ME "));

If I am not wrong this line is not useful (modelDefault is called some lines below).

Bertrand.

You are right the line is wrong, I recently found this when working on the software for the ERSKY9X board.
The line should be:
strcpy_P(g_eeGeneral.ownerName,PSTR("ME "));
I've changed it in er9x, and will commit it soon, we have the DSM2 changes to commit as well and my sources are not quite ready to commit this as well.
Whether this revised line gives you a warning as well remains to be seen, but it performs the correct function of setting a default ownername.

Mike.

Yes it will remove this warning, no problem.

But have a look in eeReadAll (if I am right, this is the only place where generalDefault is called):
Then the "ME " or whatever will be overwriten!
Am I missing something?

Bertrand.

It looks to me like the code finds the EEPROM is bad, so creates a new (default) general image, and writes that to the EEPROM, then creates a new (default) model and write that to the EEPROM. Originally the "ME" went into the model and did get overwritten, but my correction above puts the "ME" in the ownerName of the general (where it should have been all along) and does get written to the EEPROM.

Mike.

MikeB wrote:It looks to me like the code finds the EEPROM is bad, so creates a new (default) general image, and writes that to the EEPROM, then creates a new (default) model and write that to the EEPROM. Originally the "ME" went into the model and did get overwritten, but my correction above puts the "ME" in the ownerName of the general (where it should have been all along) and does get written to the EEPROM.

Mike.

Understood, another copy paste problem then
But be careful, it will remain that strcpy will copy 10bytes + the '\0' which means that myVers will be overwriten.
I would prefer a strncpy correction on this line 50 and then on line 81 (it will remove the warning that I can see). But I will perfectly understand if you fill the myVers after this line. I am almost sure that it will save flash if you use this last method.

Side note: in gruvin9x all these spaces chars are stored in EEPROM as '\0'. It saves both flash and EEPROM. And warnings

I agree that strncpy would be better. I'll have a look at storing \0 instead of spaces when I get a moment.

Mike.