Thread Tools
Jun 02, 2018, 12:17 AM
Registered User
nopkorn's Avatar
Quote:
Originally Posted by roalddogge
Hi Nopkorn,

Did you cut the edges of the Pro mini ? I only could find ones with through holes

Ro
Hi Ro,

Yes, I cut it with a large scissors paper cutter. And for safety. I think cutting one out of three is enough. It should be cleaned of small copper particles. And decorate the cut. After cutting
Last edited by nopkorn; Jun 02, 2018 at 12:41 AM.
Sign up now
to remove ads between posts
Jun 02, 2018, 12:25 AM
Registered User
@athertop:

Paul your PM inbox is full.

Apologies to the group.
Jun 02, 2018, 08:06 AM
Rana
Quote:
Originally Posted by nopkorn
Hi Ro,

Yes, I cut it with a large scissors paper cutter. And for safety. I think cutting one out of three is enough. It should be cleaned of small copper particles. And decorate the cut. After cutting
Doing on grinder is a better option, everybody won't be able to do in precision with scissors as you did.
Jun 02, 2018, 11:38 PM
Registered User
nopkorn's Avatar
Quote:
Originally Posted by narpat007
Doing on grinder is a better option, everybody won't be able to do in precision with scissors as you did.
Thanks narpat007,
That's a good option. But I don't have the tools. So I have to use a simple tool instead.
Last edited by nopkorn; Jun 03, 2018 at 01:11 AM.
Jun 03, 2018, 02:06 PM
Registered User
Hi all,

so it was.... the bootloader. That was the problem why I could not write the firmware to the Orange RX. After burning the bootloader with an usbasp I was able to flash the RX successfully.

When I wanted to flash my Wolfbox 1W TX I get this massage in the end:
06.03.2018 09:03:35.182 avrdude.exe: verifying ...
06.03.2018 09:03:35.182 avrdude.exe: verification error, first mismatch at byte 0x0581
06.03.2018 09:03:35.182 0x2b != 0x2f
06.03.2018 09:03:35.182 avrdude.exe: verification error; content mismatch
06.03.2018 09:03:35.325 avrdude.exe: safemode: Fuses OK
06.03.2018 09:03:35.458 avrdude.exe done. Thank you.


is that ok or what can I do against the mismatch?

thank you !

greetings
Jun 03, 2018, 03:43 PM
Registered User
Thread OP
OK good news !

The content mismatch doesn't sound good but you should give it a try : either it failed during the programming and really you've got some bytes wrong on the chip, or it failed during verification and in this case the program is correctly flashed. Usually that's a problem with the FTDI (remember that wolfbox is flashed at 115200 bauds, and the atmega isn't able to produce precisely this baudrate, so some FTDI adapters will work fine and some others not).

As you've got an usbasp you could also in last chance burn the orangerx bootloader on it (so it will become a 57600 bauds bootloader), or directly flash the firmware with usbasp.
Jun 03, 2018, 04:05 PM
Registered User
Thread OP
Quote:
Originally Posted by gcp900
Hi everyone,

For the new bee board, I want to share with you other cheaper links for buying the components,

Capacitor 0805 0.1 uF https://www.ebay.com/itm/50pcs-0805-...53.m1438.l2649
Capacitor 3528 100 uF https://www.ebay.com/itm/5pcs-Tantal...53.m1438.l2649
Capacitor 0805 10 uF https://www.ebay.com/itm/10PCS-6-3V-...53.m1438.l2649
All 0805 resistances https://www.ebay.com/itm/0805-SMD-Ch...53.m1438.l2649
LED 0805 https://www.ebay.com/itm/50-pcs-SMD-...UAAOSwv0tVDA3q
SMA Female for soldering https://www.ebay.com/itm/SMA-Female-...AmqtVP2tlBeBFg

And as a personal recommendation Ebay is better for buying tiny and cheap things like electronic components. Aliexpress is better for bigger things which a normal cost of more than one dollar.
Thanks, I've added your list to the ULRS Mini Bee Board on the site : http://www.itluxembourg.lu/site/apmp..._the_Bee_Board
Jun 03, 2018, 04:10 PM
Registered User
Thread OP
Another guy in China made a web site describing ULRS, quite well documented.

http://www.openuav.cn/ultimate-lrs/ Of course it's in Chinese, but you can use the right-click / translate button in your browser if you're curious.

He did a good job to translate a good number of pages of the site in Chinese (citing the source, which is fair), for example http://www.openuav.cn/ultimate-lrs/soaring-in-thermal/
Jun 03, 2018, 07:12 PM
Rana
Quote:
Originally Posted by nopkorn
Thanks narpat007,
That's a good option. But I don't have the tools. So I have to use a simple tool instead.
Hi, one more feedback; the schematic is missing in the upload page, pls check and provide it to Ben to upload. That is required even if yours and some other previous ones are similar as your's component designations might be different.
Jun 04, 2018, 12:07 AM
Registered User
Thank you flipflap,

Mhhh,
I think I will try to reflash it. It is true that the ftdi board I have is only a China clone.
I think I will try it with the usbasp. I only have to find out where on the board the ISP is.

Greetings
Jun 04, 2018, 04:43 AM
Registered User
Hi ben
Why sometimes connection speed in (getting params ) is low sometimes ?
antenna is not good ? or ...
Jun 04, 2018, 09:44 AM
Registered User
Thread OP
That's inherent to the mavlink protocol and the way Mission Planner handles the parameters transmission :

It uses a single mavlink command to ask the flight controller to send all parameters. But if that fails, for example because of a lost packet, it will request parameters individually, which is much more time consuming. So a single lost packet can make the parameter transmission become much slower.

Maybe an improvement in mavlink would be to have a command to request any number of parameters in one time. Currently in mavlink protocol there are only commands to request either one parameter or all parameters (last time I checked at least).

In mission planner there's an interesting checkbox called mavlink debug. Check it and you'll see a console screen opening in background, with all the mavlink traffic. You'll see for example "request parameter blablablah" / "received parameter blablablah" and such. In particular you'll see when mission planner tries to get all parameters, and when it tries to get them one by one.

Of course the lost packet can have many causes, such as interferences or anything. You can use the spectrum analyzer feature of ULRS to find the frequencies that are the most quiet.

edit:

mavlink command to retrieve all parameters (link) the request is only two bytes (plus mavlink headers) for all parameters. Then all parameters are received in a stream.

mavlink command to retrieve one parameter (link) the request is 22 bytes (plus mavlink headers), just for one parameter. Then only one parameter is received, and a new 22 bytes request has to be issued. It's very long.
Last edited by flipflap; Jun 04, 2018 at 09:56 AM.
Jun 04, 2018, 10:29 AM
Registered User
Quote:
Originally Posted by flipflap
That's inherent to the mavlink protocol and the way Mission Planner handles the parameters transmission :

It uses a single mavlink command to ask the flight controller to send all parameters. But if that fails, for example because of a lost packet, it will request parameters individually, which is much more time consuming. So a single lost packet can make the parameter transmission become much slower.

Maybe an improvement in mavlink would be to have a command to request any number of parameters in one time. Currently in mavlink protocol there are only commands to request either one parameter or all parameters (last time I checked at least).

In mission planner there's an interesting checkbox called mavlink debug. Check it and you'll see a console screen opening in background, with all the mavlink traffic. You'll see for example "request parameter blablablah" / "received parameter blablablah" and such. In particular you'll see when mission planner tries to get all parameters, and when it tries to get them one by one.

Of course the lost packet can have many causes, such as interferences or anything. You can use the spectrum analyzer feature of ULRS to find the frequencies that are the most quiet.

edit:

mavlink command to retrieve all parameters (link) the request is only two bytes (plus mavlink headers) for all parameters. Then all parameters are received in a stream.

mavlink command to retrieve one parameter (link) the request is 22 bytes (plus mavlink headers), just for one parameter. Then only one parameter is received, and a new 22 bytes request has to be issued. It's very long.
ok thanks i check it
please explaine more for using spectrum analyzer in ULRS cc for choosing frequencies
i add two screanshoot from spectrum analyzer

edit:
sometime ulrs going to failsafe and very hot in 5v (67 degree) ? what is problem
Jun 04, 2018, 10:37 AM
Registered User
Thread OP
67C is always a bad sign as it's the maximum temperature it can measure. Very likely a hardware issue and rfm to be replaced. In turn anything can happen such as bad communication.

Always difficult to diagnose afterwards what was the initial cause.
Jun 04, 2018, 12:47 PM
Registered User

The beta version was only valid for a determined period


Please help someone. What do I do when I get this?



Quick Reply
Message:

Thread Tools