openrcforums

jhsa wrote: P.S. - I did the encoder mod as well and it is working.Started doing it the way Kaos did without the pins but it didn't go very well.. Had to use them. But all good now..

what happened there?

I had to shave the 2 screw posts a lot so the encoder comes out a little.. I have thick fingers.. the same as the brain really.. :p
then it wasn't possible to put screws there anymore..

Joao

interesting, I did not shave the post at all, I shaved the Hippo board tab and a little at screw tip.
as long as it functions as you wanted, doesn't matter how it is done.

It's working.. the only problem I see is if it needs replacement...
Another problem is if someone install it the wrong way.. It already happened. But it wasn't so difficult to do the mod. we don't want to rush doing it though..

João

gohsthb wrote:If you commit the sources, the Linux people can grab the svn and build it themselves.

Sources just committed, I've asked Erazz to do a build.

Mike.

I have installed the new version (Rev 362) of Eepe on my machine. Set it up for the M128 and then flashed a new copy of firmware. All went well with USBasp mcu set for m128... The model memory showed as having one model that took up 37 bytes with 1740 free... Something is wrong here. Eepe reports back that Bytes Used: 102, Bytes Free: 1740, Bytes Total: 4096, so there is some agreement apart from what should be free. It it does look like there is no more model space than what we had with the M64...

Following that step it was time to load up some models from an old file. I did that by copy pasting each model into a new file before burning that to the EEPROM. All seemed to go well, it was telling me that it was writing 4096 bytes of data. The models all showed up fine and a could read them back to Eepe. Bytes used 1379, Bytes Free: 450, Bytes Total: 4096

So I am left wondering what I had set incorrectly... Did I really install a M128 or did I resolder the M64 back in?

Under eepe preferences you have to set the processor type, not just in the burn configuration.
-Gohst

Yes. The preferences was set for the m128 along with setting the USBasp for the m128 .

I was just checking that out on mine. My numbers don't seem to add up either. Not as bad as yours though. I get mine is only a difference of 404, maybe it is reserving some space for model copying and resaving. I just created a new eeprom file with 1 default model. Bytes used 105, bytes free 3660. Difference this time is 331.

-Gohst

I think eepe can't calculate anymore.. just like me.

sounds like a bug is stealing the memory. Flap30 just has a fat bug.

The numbers don't add up due to bytes used by the file system. Space is allocated in 16 byte chunks, but one of these is a link to the next chunk. The first 64 bytes are directory control, so these are 'lost' as well. We have 252 16-byte blocks for data, so we 'lose' 252 bytes. Each model is listed with the exact number of bytes is occupies. They may be some bytes left in the last 16 byte chunk it isn't using, but these are not available for another model.

Flaps30: You may have a problem due to being an early adopter before a few bugs were ironed out. You could try the following.
1. Back up your EEPROM!
2. Read your EEPROM into eepe.
3. Create a new blank EEPROM.
4. Drag and drop the general settings from your EEPROM into the blank one.
5. Drag and drop all the models.
6. Write the new EEPROM back to the Tx.

If that doesn't work, please post your EEPROM and I'll have a look at it.

Mike.

MikeB wrote:Flaps30: You may have a problem due to being an early adopter before a few bugs were ironed out.

Sounds like that might have been part of the problem. This evening I put on Open9x and tried again burning Er9x onto the TX. That has sorted it out.

Yes I did make a new model list using the method you described on the very first attempt, and that was the list that I also finally used.. So all is well.. Thanks guys.

Now all that is required, is the software for the vario.. Ideally something that is suited to Rainer's device.. It would be great if you could get some help writing the software Mike. Er9x (not forgetting all the other work you do) would be lost or nonexistent without you. Your work is appreciated big time.

Definitely..

Ok, Just replaced the Atmega on my other radio as well.. 20 minute job this time..
I tried my own drag soldering. It worked. about 3 minute job to solder the chip on.. It's amazing, before I got this radio I never had soldered an SMD component. Now I even change chips, And understand much more about this type of electronics.. I have learnt so much..

Anyway, all went well until I got to program it..

Tried eepe, companion, with the UsbAsp programmer. Target doesn't answer sometimes and sometimes said that couldn't verify.. I was thinking it was going to be a PITA like the other one. Then decided to try my MySmartUSB Light that didn't work with the other chip..
Guess what.. Started companion, programmed the fuses, flashed er9x_128, first time no problem..
So, what the heck is happening here? this was the complete oposite from my first radio..
You know what? I don't care, IT'S WORKIN..

João

Great stuff João

I take it that the Chip Quik worked well this time.... As for the troubles with the first Birthday.. Put it all down to Voodoo.

The chip Quik still didn't want to behave like in the video. still made blobs, even with the bigger soldering iron with the flat tip at 250 degrees C. I'm starting to think that maybe I put too much flux paste on it.. but it was easier than the first one. no doubt about it..

Joao

More practice required.. Doing it with that stuff is so much easier than the other methods around, unless you have the professional kit to work with..

How many more transmitters have you to do?

none.. but I might build one just for fun.
Got 2 more atmegas 128. gotta find something to do with them

Joao

jhsa wrote:The chip Quik still didn't want to behave like in the video.

Joao

Oh, man, don't say that!!! I just bought a 4oz roll in preparation to change my chip!

Just set fuses to protect the eeprom, loaded all my models, and made some modifications to the sound board because it was an old design.. all working good.. further testing when the weather allows

João

@JustinTime

But it worked.. it's probably me doing something wrong.. but the chip was out in less than a minute..
If you have some old boards, practice on them before.. I didn't have any and didn't feel like practicing on my computer, so I had to do it on the radio the first time

Ah, forgot to mention a little problem, well it could have been a problem if I didn't go with the multimeter looking for shorts after soldering the atmega to the board..
I would never have seen this..
If you look at the picture, the brown capacitor connects pin 62 AREF to ground, and pin 63 goes to ground.. Ok, the multimeter was showing a short betwenn those 2 pins..
You can see that the cap is shorted on it's side (bottom). It was a bit of chip quik that jumped and landed on the cap
well I did shake that chip out of the board cos I couldn't lift it as I didn't have the right tools.

João

Jhsa: you are officially crowned as 'Mad scientist', what's that spider web and goo on the right side!

Who put that there? not me. It wasn't there before

jhsa wrote:The chip Quik still didn't want to behave like in the video. still made blobs, even with the bigger soldering iron with the flat tip at 250 degrees C. I'm starting to think that maybe I put too much flux paste on it.. but it was easier than the first one. no doubt about it..

Joao

I believe, that this low temperature of 250 degrees is the reason why.
I have my soldering iron set up for around 320 degree even for normal soldering jobs. And you have to get the normal solder flowing, before it can mix up with the chipQuick

Reinhard

True, could have been that.. I normally use my thin(ish) tip at around 400ºC, but as I was using a bigger tip I decided to use a lower temperature.. It did work, just not the way I saw in the video..

I think that by using a higher temperature I have less chance of burning components when soldering as it is a very fast operation. For example, touching the pins of the atmega after soldering them is a very fast operation. The solder melts instantly..
Maybe I'm completely wrong here, but it has been working for me and I don't remember burning a component by overheating it.
Actually I did.. when using lower temperatures.

João

yes, contrary to popular belief the risk of burning components is actually higher when using a lower tip temperature. It's because with a high tip temp, the solder melts almost instantly before the heat has a chance to flow into the component. With a low tip temperature you have to hold the tip there longer which means the component itself gets more thermal stress. For this chipquick stuff, I recommend keeping the tip temperature pretty much the same as for normal SnPb or SAC solder, which for me is 350degC to 370degC. As Reinhard mentioned, you need to reach liquidus of the base solder material, then the SnBi chipquick can blend and lower the overall alloy temperature to allow desoldering.

@ jhsa, 400degC is too much. It sounds like you're compensating for an improper tip by cranking up the heat. I recommend you invest in a tip which has a larger neck and tip surface area so you can push enough heat flux into the solder without going above 370degC tip temp.

jbeebo wrote:@ jhsa, 400degC is too much. It sounds like you're compensating for an improper tip by cranking up the heat. I recommend you invest in a tip which has a larger neck and tip surface area so you can push enough heat flux into the solder without going above 370degC tip temp.

I was able to desolder the chip with Chip Quik using a temperature of around 220°C indicated on the station. I now doubt that it was telling the truth and the temperature was probably more like 280/300°C... I was using a short wide (5mm) screwdriver tip for that part of the work, that certainly would have helped in the process, as I doubt that a normal 1 or 2mm tip that was fairly long would have done the job.

I think my chip is fried. I can't see no shorts under the magnifying glass and I checked the wires from the connector to the board and all is fine yet I get the 'target doesn't answer' error. I don't have the battery installed but I have the encoder installed and the sound module (emartee) installed. I never had the transmitter running. It's new and I just did the mods and I'm trying to run it for the first time, starting with programming the new chip.

That's what avrdude reports:

avrdude.exe: set SCK frequency to 8000 Hz
avrdude.exe: error: programm enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.


avrdude.exe done. Thank you.

Ouch! You mean you bought a new TX (and programmer) and then proceeded to do the rotary encoder mod and all the other ones including changing out the M64 for the M128 and at no time in the history of the TX have you applied power to it?

Is this your first and only 9x transmitter?

There are a large number of threads around concerning the error you are having. Have you looked at them?