I didn't get my 4.5V regulators until about 5:30 this afternoon, but it's installed, and so far I'd say it's a go.
With the 4.5V regulators, the VCC measures 4.451V. With a fully charged flight pack battery of 5.2V, there's no problem at all with the 3V pulse height from the Futaba FASST receiver.
Just for fun, I rigged up a variable regulator, so I could reduce the voltage of the receiver, while leaving the Red board at 5.2V. The reason for this is to turn down the voltage enough so that the receiver is forced to put out even lower amplitude pulses, just to see how low it can go. As the video shows, 2.65V pulse height is as low as I can get.
I'll certainly post any and all info about the regulator used, but I'd like to let Bill look over the data first, and see if there's anything else he would like me to test. There could easily be a better choice for the regulator as well, but I'm happy so far. I still have one stock red board, but barring any needed comparisons, I'll change out the regulator on that one tomorrow.
Bill, is there any way to see the GPS status (number of sats, signal levels, etc)? Since it's running right at the minimum voltage, it would be interesting to compare the full voltage version, to the reduced voltage. There's only a few tenths of a volt difference between running the stock board at 5.0V (VCC about 4.85V), and the modified board with a VCC of 4.5V, so I don't anticipate a noticeable difference in GPS performance.
Sadly, there won't be any flight tests this weekend for me. The cold front last night left us with "15-25 mph, gusting to 40 mph" wind forecasts. There's a little hope for late Sunday afternoon, but not too promising.
I just got my UavDevBoard. I programmed it with Aileron assist 1.8 and put in some waypoints.
Trying all the settigs before the big day (tomorrow if I can) I wasn't able to have my esc working.
The esc is connected to the board to have altitude hold.
It seems that the esc (a Scorpion) try to arm before to have any good signal from the board (10").
So it doesn't arm at all.
Forgive me if this was already asked but I wasn't able to find an answer.
For some reason, your last couple posts don't give me the "reply to this" option, so I can't reply directly below them. Have I ever mentioned how much I hate this ning format...
FWIW, I'm not any sort of expert in hardware design. I gave some thought to the level shifters, and Sparkfun has a neat little board for less than $2 that will shift a couple signals. Unfortunately, it would require a 3V supply, which isn't readily available on the receiver. By the time you shifted 4 channels, it would get really messy with cables, even if I did a plug in adapter board.
I had also considered the diode solution, but would rather change the regulator. I'm pretty confident that a 4.5V regulator will take care of everything nicely. If I'm wrong, it certainly won't be the first time. If I'm REALLY wrong, I have another CPU on order as a spare :-)
Hi Bill,
Thanks for your suggestions.
As soon as I get home, I'll surely try on low voltage power supply.
The strange thing that I've haven't already figured out, is why input 1 and 2 had no problem at all!
I know that the first 2 inputs are on one port on the PIC and input 3 and 4 are on the D port. Maybe this port has a little different trigger? Is there a possibility that we need a different configuration?
I'll post the results as soon i get home to test.
See you later,
Andrea.
FYI - I don't use channel 3 but have had no problems with the channel 4 input for selecting the mode. I use a Futaba R607FS (2.4GHz) and a Dimensions Engineering SportBEC to power everything. I've flown with this configuration and haven't noticed any problems so far.
Hi Bill,
I really need some assistance.
I've tested so far 4(!!) different red boards, but no one seemed to correctly parse the signal on input 3 and 4.
I tested them using stock sparkfun self-test firmware and also with self-compiled test firmware downloaded from here.
I've also made tests with AileronAssist firmware (without much success due to bad input channel 4 recongition).
I don't really know what I'm doing wrong, and it seems quite strange that all the 4 boards where bad.
I'm testing with futaba radio equipment, powered with 5/6 Volt stabilized power supply.
Input 1 and 2 are perfect, but input 3 and 4 aren't working at all, or seems to sometimes read one pulse sporadically.
Do you have any suggestion?
You can also contact me by email, so we can go to further investigation.
Thanks.
Andrea.
I had similar issues as Scouser trying to connect my PICkit 2 to the board while it was buried in the fuselage. I ended up getting two servo extensions, cutting off the female ends and soldering them directly to the DEVboard. The male ends were CA'd together to create a connector to the PICkit 2. When finished uploading, I just tuck the connector between the foam and fuselage wall.
There seems to be a bit of interest in getting the dev board to work with the UBLOX chipset GPS receivers, i've seen several people ask about it, and Bill has commented that all is required is to write appropriate firmware. My dev board should arrive tomorrow, along with a GS407 GPS unit, which is the U-Blox 5hz chipset with the Sarantel helical antenna. (i'm more interested the potentially more robust reception of the helical antenna than i am with the 5hz update rate). Anyway, i've taken it upon myself to rewrite a version of gpsParse to suit the UBX protocol. So far i've gone through both protocols and found the appropriate messages and variables that need to be parsed to get the same info as what the SIRF protocol provides. The only ones i'm having trouble finding direct equivalents for are the Mode1, Mode2, Nav Valid and NAV Type variables.
NAV Type appears to include all the same data as the Mode1 and Mode2 variables, and Nav Valid is 2 bytes composed of one status bit and 15 reserved bits.
Furthermore, none of these variable appear to be actually used in the code other than being declared in a few places and assigned in the parsing code. (looking at the MatrixNav 1.7 code at the moment)
So i was hoping for some guidance, on whether this information is actually required or not. I think i can get most of the relevant info out of the UBX messages, it would just mean reading a bunch of messages that we probably otherwise don't need to parse.
Also if you can offer any guidance on the best way to structure the header files so that the code could be integrated back into your code base later on, that would be most appreciated. At the moment i was just going to run a seperate header file called gpsParseUBX, and select between it and your original one using #IFDEF's and a #DEFINE UBX in the appropriate places. Is this the best way to proceed?
I'm getting ready to test fly the red board with AileronAssist 1.8 in the BusyBee. I'm a little confused about one thing, however. It is possible to use the your RC transmitter to choose between RTL and Waypoint modes? As I understand the documention, the middle setting of a three-position toggle is stabilization mode in all versions of the code, but do you have to burn new code (1.7 vs. 1.8) to choose between waypoint or RTL mode?
Is there any way to do what we do with ArduPilot, which is "middle toggle" = waypoint, while "up toggle" = RTL? (If you unplug the GPS, you get stabilization)
I've not had much luck with the ICD2 programmer from Sparkfun so I went with an option that Bill had mentioned. The PICkit 2 was purchased from Microchip for about $40.00 including the USB cable. This is less than 1/2 the cost and about 1/2 the size of the Sparkfun programmer but you have to make a minor modification. The connector won't fit over the 6 pins of the Devboard because of the polarizing tab. Bill mentioned he got around this by removing the tab but I was afraid to try this and possibly damage the board. What I ended up doing was removing the top cover of the PICkit and removing enough of the cover around the connector to avoid contact with the Devboard polarizing tab.
Replies
I didn't get my 4.5V regulators until about 5:30 this afternoon, but it's installed, and so far I'd say it's a go.
With the 4.5V regulators, the VCC measures 4.451V. With a fully charged flight pack battery of 5.2V, there's no problem at all with the 3V pulse height from the Futaba FASST receiver.
Just for fun, I rigged up a variable regulator, so I could reduce the voltage of the receiver, while leaving the Red board at 5.2V. The reason for this is to turn down the voltage enough so that the receiver is forced to put out even lower amplitude pulses, just to see how low it can go. As the video shows, 2.65V pulse height is as low as I can get.
BTW, the video was done in a single take, so lets keep the video critique to a minimum :-)
http://www.radrotary.com/RedBoard_4.5VCC.wmv
I'll certainly post any and all info about the regulator used, but I'd like to let Bill look over the data first, and see if there's anything else he would like me to test. There could easily be a better choice for the regulator as well, but I'm happy so far. I still have one stock red board, but barring any needed comparisons, I'll change out the regulator on that one tomorrow.
Bill, is there any way to see the GPS status (number of sats, signal levels, etc)? Since it's running right at the minimum voltage, it would be interesting to compare the full voltage version, to the reduced voltage. There's only a few tenths of a volt difference between running the stock board at 5.0V (VCC about 4.85V), and the modified board with a VCC of 4.5V, so I don't anticipate a noticeable difference in GPS performance.
Sadly, there won't be any flight tests this weekend for me. The cold front last night left us with "15-25 mph, gusting to 40 mph" wind forecasts. There's a little hope for late Sunday afternoon, but not too promising.
Cheers,
Rusty (well equipped Den)
I just got my UavDevBoard. I programmed it with Aileron assist 1.8 and put in some waypoints.
Trying all the settigs before the big day (tomorrow if I can) I wasn't able to have my esc working.
The esc is connected to the board to have altitude hold.
It seems that the esc (a Scorpion) try to arm before to have any good signal from the board (10").
So it doesn't arm at all.
Forgive me if this was already asked but I wasn't able to find an answer.
Any help?
Thanks and best regards.
Ric
For some reason, your last couple posts don't give me the "reply to this" option, so I can't reply directly below them. Have I ever mentioned how much I hate this ning format...
FWIW, I'm not any sort of expert in hardware design. I gave some thought to the level shifters, and Sparkfun has a neat little board for less than $2 that will shift a couple signals. Unfortunately, it would require a 3V supply, which isn't readily available on the receiver. By the time you shifted 4 channels, it would get really messy with cables, even if I did a plug in adapter board.
I had also considered the diode solution, but would rather change the regulator. I'm pretty confident that a 4.5V regulator will take care of everything nicely. If I'm wrong, it certainly won't be the first time. If I'm REALLY wrong, I have another CPU on order as a spare :-)
Rusty
Thanks for your suggestions.
As soon as I get home, I'll surely try on low voltage power supply.
The strange thing that I've haven't already figured out, is why input 1 and 2 had no problem at all!
I know that the first 2 inputs are on one port on the PIC and input 3 and 4 are on the D port. Maybe this port has a little different trigger? Is there a possibility that we need a different configuration?
I'll post the results as soon i get home to test.
See you later,
Andrea.
FYI - I don't use channel 3 but have had no problems with the channel 4 input for selecting the mode. I use a Futaba R607FS (2.4GHz) and a Dimensions Engineering SportBEC to power everything. I've flown with this configuration and haven't noticed any problems so far.
I really need some assistance.
I've tested so far 4(!!) different red boards, but no one seemed to correctly parse the signal on input 3 and 4.
I tested them using stock sparkfun self-test firmware and also with self-compiled test firmware downloaded from here.
I've also made tests with AileronAssist firmware (without much success due to bad input channel 4 recongition).
I don't really know what I'm doing wrong, and it seems quite strange that all the 4 boards where bad.
I'm testing with futaba radio equipment, powered with 5/6 Volt stabilized power supply.
Input 1 and 2 are perfect, but input 3 and 4 aren't working at all, or seems to sometimes read one pulse sporadically.
Do you have any suggestion?
You can also contact me by email, so we can go to further investigation.
Thanks.
Andrea.
There seems to be a bit of interest in getting the dev board to work with the UBLOX chipset GPS receivers, i've seen several people ask about it, and Bill has commented that all is required is to write appropriate firmware. My dev board should arrive tomorrow, along with a GS407 GPS unit, which is the U-Blox 5hz chipset with the Sarantel helical antenna. (i'm more interested the potentially more robust reception of the helical antenna than i am with the 5hz update rate). Anyway, i've taken it upon myself to rewrite a version of gpsParse to suit the UBX protocol. So far i've gone through both protocols and found the appropriate messages and variables that need to be parsed to get the same info as what the SIRF protocol provides. The only ones i'm having trouble finding direct equivalents for are the Mode1, Mode2, Nav Valid and NAV Type variables.
NAV Type appears to include all the same data as the Mode1 and Mode2 variables, and Nav Valid is 2 bytes composed of one status bit and 15 reserved bits.
Furthermore, none of these variable appear to be actually used in the code other than being declared in a few places and assigned in the parsing code. (looking at the MatrixNav 1.7 code at the moment)
So i was hoping for some guidance, on whether this information is actually required or not. I think i can get most of the relevant info out of the UBX messages, it would just mean reading a bunch of messages that we probably otherwise don't need to parse.
Also if you can offer any guidance on the best way to structure the header files so that the code could be integrated back into your code base later on, that would be most appreciated. At the moment i was just going to run a seperate header file called gpsParseUBX, and select between it and your original one using #IFDEF's and a #DEFINE UBX in the appropriate places. Is this the best way to proceed?
Regards
Adam Bellchambers
I'm getting ready to test fly the red board with AileronAssist 1.8 in the BusyBee. I'm a little confused about one thing, however. It is possible to use the your RC transmitter to choose between RTL and Waypoint modes? As I understand the documention, the middle setting of a three-position toggle is stabilization mode in all versions of the code, but do you have to burn new code (1.7 vs. 1.8) to choose between waypoint or RTL mode?
Is there any way to do what we do with ArduPilot, which is "middle toggle" = waypoint, while "up toggle" = RTL? (If you unplug the GPS, you get stabilization)
-
6
-
7
-
8
-
9
-
10
of 14 Next