C3ii Booster Pack - high-performance GPS-Aided Inertial Navigation System (INS)

It looks interesting to me. But then my tastes are a bit eclectic...

unless it is an UUGV -- why only Bluetooth??? (Unmanned Un-Guided Vehicle i.e. intelligent (AI) algorithms with stored flight plan)...

My tastes always were a bit strange ( :-) ) so.... assuming the parts are available -- I might well be interested in a board.

Maybe you should think about an Ultrasonic sensor as well -- for landing time...

Sounds like it might be expensive gear for a hard landing.

Dave Robinson said:

unless it is an UUGV -- why only Bluetooth??? (Unmanned Un-Guided Vehicle i.e. intelligent (AI) algorithms with stored flight plan)...

Hi Dave,

the RN-41 is a Class 1 Bluetooth; it delivers up to a 3-Mbps data rate for distances up to 100 meters.
I thought about using the XBee 868LP (Up to 2.5 miles (4 km) w/2.1 dBi antenna, up to 0.6 miles (1 km) w/PCB embedded antenna) but decided to use Bluetooth for the on-board radio since the XBee 868LP will only allow a RF throughput up to 50 Kbps .
I'm shure you've noticed the connectors on the board --> some more radio options possible!

Well, regarding the costs:

RN-41: $27.08 (Digikey 740-1007-ND)
BMP180: $5.46 (Digikey 828-1027-1-ND)
PA6C GPS: $20
MS5611-01BA03: $14.50
MPU-9150: $26

The prices above are for one piece each. So, I don't think that it's that expensive when build in quantities (nor when only in single units). 

Shouldn't be a problem to add other sensors when needed (i.e. ultrasonic rangefinder) since the LM4F120H5QR has lot's of interfaces (and some of the were available on a connector).

Rgds
aBUGSworstnightmare 

Hi there,

now that my Stellaris I2C Driver API is in place (http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/473/t/235926.aspx) I had the time to proceed and build some routines to use it.

I've started with some software routines to interface with a 128x64 pixels OLED display which uses the SSD1308 controller. The driver is working but needs some touch-up before it will get posted in the Stellaris sharing forum.

Here are some pictures. The OLED is a 0.96in I2C module from wide.hk (http://www.wide.hk/products.php?product=I2C-0.96%22-OLED-display-module-%28-compatible-Arduino-%29) which is also available with area colour.

The code will allow flexible string display, centered display and image printing on the OLED. It is comparable to the 'simple display' found in the EVALBOT software examples. Maybe some scrolling commands will be added too.

Since my Stellaris I2C driver API takes the I2C-bus as a calling parameter, using more than one OLED in the system is an easy task.  

Rgds
aBUGSworstnightmare 

Could we use this to upgrade the CF18's in Canada?

I mean it looks like we're cancelling our new stealth fighters and will be buying new doilies instead for the dining room tables in our house of parliament...

So now we have to do something -- and this guidance unit looks pretty slick -- I could forward your note to our minister of defense -- it's better than what they plan I think... ;-)

@ Monsieur: Hard to accommodate "both" 16 USD orange juice and stealth fighters - eh?  (thank Ms. Angela)

@ Jorge/Bug: very nice - great dedication, attention to detail.  Would appreciate similar photo of the multi-rotor "craft."   And - how many addresses does that display accommodate?  Is the address selection realized by certain I2C "address pins" being brought out - on the flex cable?

cb1- said:

Would appreciate similar photo of the multi-rotor "craft." 

Hi cb1,

the multirotor is nothing special; the frame is sold by a friend of mine and is called 'Flyduspider' (as usual: google know's 'em all).

cb1- said:

And - how many addresses does that display accommodate?  Is the address selection realized by certain I2C "address pins" being brought out - on the flex cable?

The OLED has only one address. Each OLED is connected to another I2C module.

Drawing simple 'bitmaps' is done but I'm not quite satisfied with the routines. I think I will post them in the Stellaris sharing forum by the end of the week (at the latest).

By the way: any idea/recommendation how to re-write/modify UARTStdio to print on the OLED?

Rgds
aBUGSworstnightmare

P.S. Scan the code with a QR-Reader ;-)

Clear from your great photos that you've made more progress - nicely done!  (and we will google as you direct)

Pity that the OLED maker did not foresee the "bus connection" of multiple of these displays.  Contrast simply terrific.  (and great job of photography by you, too.)  Have taken a "few" pictures of operating, emissive displays in my day - yours are super!

At a loss to grasp your request for idea on (UART to I2C) signal conversion!   Is that what you seek?  I fear that implementing the I2C protocol - ACKs especially - via a UART (even a clocked one) would be an unwelcome/unwanted challenge.

BTW - "failed, past OLED maker Osram" had nice write-up on care/handling/decode of mono bit-maps - believe that you can still review.  (again, google)

cb1_mobile said:

At a loss to grasp your request for idea on (UART to I2C) signal conversion!   Is that what you seek?

 

No, sorry for not beeing clear on this!

I want to write a routine which I can use for console output on the OLED. In case of using the UART is is this:

//
// Initialize the UART for console I/O.
//
UARTStdioInit(0);

//
// Print a string to show that the console is active.
//
UARTprintf("UARTStdioInit ...\n");

Then I need to write of modified version of UARTprintf() which prints to my OLED-console instead of printing to UART0 (as shown above).

aBUGSworstnightmare

Aha - now I see.

Yesterday TI "friend" Dave Wilson made great - applicable post advising that we should, "keep" all original Stellaris functions and library content as "original" as possible.  Thus - as you appear to suggest - you should create a, "New Function" - UART2OLEDprintf() (my suggestion - to comply w/Dave's advice).

However - the choice of UART - rather than your already, well-documented I2C application post - still strikes as strange.  Would not a better choice be, "I2C2OLED" - where you "preload" all of the specifics for that particular OLED - and employ as much of your existing I2C code as possible?  This makes the most sense - I believe...

BTW - your detailed I2C write-up seems to echo some of my earlier "shared" post - targeting the LX4F and I2C.  (believe I was 1st to highlight use of "GPIOPinTypeI2CSCL()."   TI poster - in that early post - appears to have "missed" that (new at the time) PinType requirement...   The detail and care w/in your I2C write-up are great - add much clarity - which is so necessary.  (devil lives in such detail)

One last comment - have been in the display biz for 25+ years - as neat as that OLED appears - IMHO it has insufficient rows/columns (i.e. its too small) to serve as a "real Console!"   (you will spend all of your time - endlessly scrolling)  Quality (hi contrast, wide view angle, bright Led b/l) QVGA TFTs - in 2.2-2.8" diagonals - can be had for less than 18 USD in 100 pc (lot) quantities.  Most have in-built controllers - thus require no constant refresh - you write only to alter the display content.   Such a QVGA - oriented in "Portrait Mode" - can accommodate 16 rows of 20 pixel tall text (other sizes possible) - which far exceeds that of your current OLED...

You will also soon discover that "finding/appropriating" ANY existing photo/icon/diagram - in non gray-scaled Mono - is extremely difficult.  Use of a color TFT - as I propose - opens the door for the easy import of most any photo/icon/diagram.   This is the "death knell" to the mono-only display. (which bought me ocean house, boat etc.)   Only our "tech world" would use such Mono (pixel On/Off) limited display - 99%+ "commercial" Aps all have moved to color - primarily to accommodate image import and increasingly to present video...

cb1_mobile said:

Would not a better choice be, "I2C2OLED" - where you "preload" all of the specifics for that particular OLED - and employ as much of your existing I2C code as possible? 

Hi cb1,

it will be an I2C2OLEDprintf() for shure with the same functionality as it's UART counterpart.

I only did a brief inspection of the 'void UARTprintf(const char*pcString, ...)' routine (find the source in Stellarisware-->Utils folder), but it shouldn't be to complicated to replace all the 'UARTwrite()' calls with my corresponding I2C routines. I don't think that I will have to touch all the 'formatted output' stuff (i.e. %2d ...).

A replacement for 'void UARTStdioInit(unsigned long ulPortNum)' --> 'I2CtoOLEDStdioInit()'  should be the easiest part to do.

To be honest: the OLED is only a secondary display for the unit! It hast the Bluetooth downlink to talk to a tablet/pc (at distances up to 100m) and it will feature a pure telemetrie downlink with long range (one of the - 'til date - undisclosed features). 
So, there will be not much need to 'scroll' the OLED content. Nevertheless, I think it will be of particular use to display some status infos, and during code testing/debugging.

Yes, a TFT would be nice! I thought of using a 2.2in Touch-TFT with SPI interface on the craft but I think there's no need for it (because the BT an Telemetrie downlink).

Rgds
aBUGsworstnightmare 

Hi back,

You are ambitious - no doubt.  Wish you the best of luck - keep in mind that the "missile" cannot fly until all of the paper work is complete!  (and when stacked - is taller than the missile...)

We sell many displays for such "robust/field" applications.  Tablets are bit too pricey to risk in such field environments.

Don't let Dave Wilson see your "replacement" of UARTStdioInit() !   Instead - suggest you "augment" that function with our jointly agreed, NEW, "I2C_2_OLEDStdioInit().  As Dave says - in this way the functionality of the Stellaris library remains intact - although you've personally extended your current/resident copy.

You may also give some consideration to other, often "offending" RF sources at or nearby your test range.  Wireless has appeal - but my many years has always shown that, "Hard Wire" gets through - while RF is most always, "iffy!"  (And sometimes unusable - and then what?)

Hi there,

looks like the guys at TI also liked my idea (or at least had a similiar one) of the C3ii INS (see alos http://e2e.ti.com/group/microcontrollerprojects/m/msp430microcontrollerprojects/664688.aspx ) Booster Pack: http://www.ti.com/tool/boostxl-senshub

TI now offers a Sensor Hub Booster Pack BOOSTXL-SENSHUB which features the same senors (Invensense MPU-9150 and Bosch Sensortec BMP180) and - in addition - adds some more. They also added the EM-connector which allows to connect a GPS or WiFi to the board.

The BOOSTXL-SENSHUB sells for $49.99 and is (at the time of writing) available at the TI eStore. Get one until stock lasts!

aBUGSworstnightmare

P.S. Too bad that I couldn't participate in the last TI Booster Pack design challange!