DragonPro

Stuff I am working on
Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

DragonPro

Post by Daniel Wee » Sat 07 Mar 07 2009 8:17 pm

The prototype board appears to be working now, even with the misaligned pins. We are starting off with the XT at 8.0MHz and then activating a 10-times PLL to kick the clock up to 80MHz, giving us the instruction clock (Fcy) or 40MIPS. This is twice as fast as what the DragonOSD is running at (20MIPS).

BOB-4 SPI interface working at full speed. Possibly a bit faster than on the DragonOSD due to better status checking to allow for higher rates to be pushed. On the 4.8l version of DragonOSD, the SPI rate was in the region of 76kB/s. On the current DragonPro code - we are pushing 102kB/s. This is purely transfer rate, of course. Render rate remains around 7kB/s as limited by the BOB-4.

I2C EEPROM interface is working. Clock rate is currently set at 1MHz and seems to be working without problems at this speed. The write cycle for 10-integers is 2.96ms while the read cycle for 10-integers is 0.192ms. Writing takes longer because of the need to erase the EEPROM before writing and then verifying. We have 128kB at our disposal so we'll need to partition this up for waypoints, logging and configuration data.

ADC interrupts are working. We are scanning 6-channels at 20kHz. The current channel is being averaged every 1000 times, giving us a reading 20-times a second. We may have to look into speeding this up.

What we need to do now is to figure out a new way of dealing with screen display elements so as to cut down amount of data that needs to be transferred. This could mean separating labels from values and rendering labels only once and all at the same font size. The problem is that some of the labels are dynamic and turn on and off accordingly.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Sat 07 Mar 07 2009 8:50 pm

Upon inspection - the standard on-screen labels aren't that many after all. We're talking about:-

Top left - V, C
Top right - kph, m
Bottom left - V EXT, A, mAh
Bottom right - LOS, m, m

The bulk of the data probably results from the 3-lines used by the compass recticle set, or more specifically the second and third lines. This comprises the recticle itself, the end arrows, and the home indicator. For the third line, it might make sense to specifically erase the "H" and re-draw just the "H" rather than the space filled line. That could save considerable data.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Sat 07 Mar 07 2009 10:14 pm

First prototype:-
IMG_0977a.JPG
DragonPro prototype 1
IMG_0977a.JPG (70.32 KiB) Viewed 8518 times
Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Mon 09 Mar 09 2009 8:55 am

Okay, current status:-

1. SPI to BOB-4 optimized and working
2. UART circular buffer RX working
3. UART TX working
4. I2C to EEPROM read/write to first 64kB checked and working
5. ADC interrupt working
6. GPS baudrate setting working
7. GPS NMEA strings reception working
8. GPS NMEA processor written, not checked
9. Relative position function written, not checked
10. Autopilot function written, not checked
11. Multiple waypoint handling system written, not checked
12. Primary loop written, not checked

So most of the navigational system is written. The OSD section still needs to be done, as well as the user settings menu system. Then the PWM input/output system needs to be done as well. Next up is to check that all the sensors are working correctly.

1. Analog sensors
2. I2C sensor interface
3. PWM input capture
4. PWM output
5. PWM passthrough
6. PPM stream capture
7. Initializing settings variables
8. Loading settings from EEPROM
9. Loading waypoints from EEPROM
10. Logging of data to EEPROM
11. Modularized OSD display system
12. User menu

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Tue 10 Mar 10 2009 2:59 am

Phew! That was some tricky stuff - the dsPIC33F is quite different from the dsPIC30F where ADCs concerned. Anyway, work done so far:-

1. Finally got the SPI routines to handle sending fast data to the BOB-4 without hanging
2. ADC with DMA finally working - voltage and current readings are working
3. GPS NMEA processor appears to be working
4. New modularized display system seems to be working

That might not look like much but it is a lot of work. Now I need to fully verify all ADC channels are being sampled. Also need to start thinking about smart rendering screen stuff, ie. no need to redraw stuff that have not changed (eg. Voltage and other slow changing stuff). Also need to get actual GPS data going and write up the custom display components.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Tue 10 Mar 10 2009 1:32 pm

Found another tricky one - it seems that the switching PSU is having some sort of ripples at start up that causes the BOB-4 to show some lines and occasionally fail to start up properly. I had to add a control for the RST line from RG15 to allow the DragonV2 to have direct control over the reset, after starting up properly. This now works but I think I will re-design the PSU anyway. Also adjusted the VMULTx values to reflect better accuracy. IMULT2 and MAHMULT has not been set - those need a calibration setup which can come later. The inputs have been tested to work though.

Currently, I am testing an ADC sampling rate of 20kHz. The current sampling averages this out at an interval of 400-readings or 50Hz. This will cause the current usage long variable to overflow in 5.8254 hours is it was reading the maximum value of 4096 continually. In practice, it will be double or more of this time before it overflows.

Screen elements that need to be handled apart from the modularized system - alt-change arrows, LONQ/LATQ and SV indicators, the whole satellite display, compass.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Tue 10 Mar 10 2009 3:17 pm

Okay, all elements except for the alt-change arrow and the compass are done. With everything being rendered so far - a full screen takes around 58ms. This works out a to screen refresh rate of about 17.2Hz. We will need to see what happens when we render the compass as well but in practice, you won't be rendering everything at the same time. This is just the worst case scenario.

*update - with the original compass renderer - the full-screen draw cycle takes 65.2ms or so, at a 15.34Hz screen redraw rate. This is still quite acceptable. Need to add the artificial horizon renderer to see how that impacts things.

*more updates - the smarter compass renderer shaves 6.4ms off the render time, giving a total worst case draw cycle of 58.8ms. On a typical flight screen - draw cycle is 35.8ms or a 27.9Hz refresh rate. Full horizon rendering adds another 8.0ms per line giving a total of 43.8ms per normal frame, or a screen re-draw rate of 22.83Hz.

The BOB-4 still seems to get stuck after a while. Not quite sure if that is due to the use of the fast-render routines or the lack of SS0 framing.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Tue 10 Mar 10 2009 5:04 pm

Thinking about the screen-redraw rates raises a rather interesting issue. We are currently seeing full-screen redraws at a rate of about 15Hz and upwards. That's 15 screen redraws a second. But the BOB-4 datasheet says that it can only process 7kB/s of data. This means that as long as our 15 screen redraws do not add up to 7kB of data, we should be okay. Therefore, it would make sense to count how much data actually gets drawn per screen.

So, with some modifications to the code - this number appears to be in the region of 745-bytes of data per normal flight-screen with horizon. At 22.83Hz - this works out to be 16.6kB of data per second!!! With every thing turned on - we're looking at around 1230-bytes per full screen (inclusive of horizon).

Working backwards - at a 7kB/s rate - this only allows a refresh rate of 5.8-screens per second. Anything else will lead, eventually to a buffer overflow or throttling. One of the key challenges, therefore, is to reduce the amount of data that is being sent through opimization of the formatting characters and removing redundancy.

We can also lock the redraw rate to the incoming GPS data - which gives us a 5Hz re-draw rate. This seems to be quite ideal although the artificial horizon isn't going to look pretty at this speed.

Now here's the odd thing - the buffer never goes below 512 at the end of a draw though - so maybe something is wrong with my buffspace routine.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Tue 10 Mar 10 2009 10:44 pm

Okay, I admit a hardware debugger has its' uses. I've been struggling with this problem in the BOB-4 for a long long time and never did quite find the reason. Every now and then, when being pushed really hard, the system would hang and I would not know why. This would occur especially when the BOB-4 was low in buffer space.

Well, thanks to the ICD2, I now know the reason. The BOB-4 is not responding to SPI status request commands under those conditions - oddly. And this has left the loop in a waiting mode - for a result that was not coming, thus hanging the system. In the past, the watchdog would catch this and reset the system. Now I have a counter that would prevent this sort of lockup from happening.

This is a very big breakthrough actually - so now we can move on with confidence to the other parts of the code.

*update - it appears that the situation is compounded when writing stuff to an full buffer. The BOB-4 actually locks up. So, to prevent this from happening, I have instituted an 8-byte (now 16-bytes) barrier to mitigate this problem.

Daniel

Daniel Wee
Site Admin
Posts: 2073
Joined: Wed 25 Feb 25 2009 8:00 pm

Re: DragonPro

Post by Daniel Wee » Wed 11 Mar 11 2009 2:21 am

Well, the intermittent problem was reduced somewhat but it still shows up from time to time. It doesn't seem to have anything to do with the remaining buffer size. Neither does it seem to have anything to do with the _SS0 line either. So what we've now done, after instituting some safeguards in the code, is to drop the SPI rate from 101kB/s to 76.3kB/s.

In the test - the V2 is printing full bore - full-screen with everything forced on, 1437 characters in all - taking a full 91.2ms for a complete screen render, or a 10.96Hz rate. Now, this has been running for quite a while and seems to be stable. The old DragonOSD was also stable at this SPI speed so I reckon that the BOB-4 just cannot keep up with the high SPI rate. It is also possible that the slower speed is merely delaying the problem so we will have to test this to the hilt to see if it results in any lockups.

This absolute worst case render rate means that we can probably still keep up with a 10Hz GPS.

Meanwhile, another problem has cropped up. It seems that this switching PSU is really creating some rather odd problems. For one, the GPS module is not getting read properly when power-cycled. It appears to be putting out 9600-bauds of data so either it did not receive the initialization string due to the main clock being unstable, or because the rise time on the PSU is too slow. Oddly, if the reset is held and then released without power-cycling, it comes back to life and starts it's clock anew. This is rather strange because I would have thought that the clock would have counted out some time before this partial reset. Will have to look into this.

*update - as it turns out - the GPS start up is REALLY slow. Up to 3-4 seconds before data starts coming out. Once we sorted this out, we're good with the GPS.

Daniel

Post Reply