Of course last weekend was the holiday, and this week was full of adventure. I got to ride a new airplane up to Chicago (new for the airline, not new to the world). It was full of employees, so the rules were a little relaxed. Everyone was taking pictures, and the cockpit door was open the whole flight. Really fun for that part of the flight. I had to make my own way home, so that was frustrating and all the normal fun of non-revenue travel.
I ordered a EZ430 Chronos about a week ago. I needed a watch anyway, but this was too good a deal on tideals.com. $25 for the whole kit. That showed up when I got home from my trip to Chicago. Been using it as a watch for the week, but last night I tried to get the development environment going. Well the laptop has shut me down again....
The CCSv4 needs to run in eclipse. Guess what, it didn't install again. I rolled back to helios from indigo, and that was no help. I am so frustrated with this laptop, probably vista, but who knows. I'll probably go ahead and load everything on the desktop, and it'll work.
I did load eagleCAD on the laptop while waiting for a flight in Chicago, and started getting the schematic drawn. Ran out of time, and still haven't finished that. Maybe I'll have some time next week.
Stay in touch.
Sunday, April 15, 2012
Monday, April 2, 2012
Android vs iPad
Uh Oh, religion...
Well, to some people what I am talking about is heresy. Forgive me, and listen. Both Apple and Android make fine tablets for different purposes. Actually, for the common use, both are probably equal. Maybe for watching movies on a portable device, the new iPad is better. For word processing, I don't think either is suitable for long term use, but for occasional, they each are probably equal.
We aren't watching movies or word processing. We are trying to monitor something. Does a retina display help that? Not really.
The place where the iPad completely fails is in Bluetooth profiles. The iPad comes out of the box without the serial port profile (SPP). Apple rightfully says you don't need it. Not to watch movies, answer email, play angry birds or word processing. You can add it, but that is a challenge. The are things like the BlueSnap Bridge, but at best I'd call that a kludge. It only sends ASCII, no problem, but it is another box to maintain (battery charge, etc).
The Android has SPP as a standard. Many people realize this is a huge feature of the android, and are building their products to take advantage of this. There are automotive engine monitors that will do this today, and won't support iOS because of the lack of SPP.
So you say "all the aviation companies support iPads". That is true, to an extent. Certainly Jeppesen, WingX and others support iPads. WingX also supports Android, and there is a whole site dedicated to Android aviation apps. Flightplan.com, flightaware.com and others also have nice Android apps.
How about form factor. Say you have a big panel, and you want to fill it with tablets. No problem, get a couple 10 in displays, and you are good. How about a small panel, maybe 2 7inchers, and a 4inch for backup. But you say iPads only come in one size, how do they compete? (you might be noticing a pattern).
Then the argument about the enterprise. iPads work great in the enterprise, they sync email and scheduling. Okey doke, but not a 10,000 over eastern Montana they don't. You want to sync with your engine, and maybe your air data computer. That is what matters. If you need to sync with your office, you'll need a data connection to the ground (row44 maybe?). By the way, Androids' sync to email and scheduling just as well.
Licensing and releases, well the android probably will win that. Apple comes along and thinks what is best for iTunes, not your charts. Remember the iOS4 trouble when the iOS would clean up your "old" files for you, thinking they were old movies or songs. That low altitude enroute chart that was 25 days old didn't survive, and you had to scramble to find a sectional or high altitude chart to cover for you. You can vette out the system that works for you, and take or not upgrades for your display.
How about RIM or Windows. Maybe, they will work. I still haven't seen a windows tablet, and the PlayBook is only available in one size. If someone has time, we could work on it together (you want to send me one, I'll play with it, I promise :-). Critical mass is the magic here, are they available, can I get one, and what do I need to develop for it?
The SDK for the iPad and Android seem to cost about the same thing, nothing. Writing for the iPad is in Objective-C. The Android is Java sorta. Both languages are object oriented, with a C base. There are many people in the world who can develop for them, so that wouldn't be a reason to pick one over the other. Apple tends to control the iTunes store, and that is about the only way to deliver apps to the iPad. Android allows others to host and distribute apps, you aren't locked in to the Android market. There are risks getting apps from a non-android or non-apple market, but most are honest, so they work. There are malicious apps in both market places, and they get cleaned up fairly quickly.
For me, I have chosen the Android eco-system because of the openness, or at least appearance of openness. I havn't spent a dime on software, I have a demo cooking, and it'll work with my stuff as I designed it. Your mileage may vary, and I'll listen to any argument.
Keep on soldering.
Well, to some people what I am talking about is heresy. Forgive me, and listen. Both Apple and Android make fine tablets for different purposes. Actually, for the common use, both are probably equal. Maybe for watching movies on a portable device, the new iPad is better. For word processing, I don't think either is suitable for long term use, but for occasional, they each are probably equal.
We aren't watching movies or word processing. We are trying to monitor something. Does a retina display help that? Not really.
The place where the iPad completely fails is in Bluetooth profiles. The iPad comes out of the box without the serial port profile (SPP). Apple rightfully says you don't need it. Not to watch movies, answer email, play angry birds or word processing. You can add it, but that is a challenge. The are things like the BlueSnap Bridge, but at best I'd call that a kludge. It only sends ASCII, no problem, but it is another box to maintain (battery charge, etc).
The Android has SPP as a standard. Many people realize this is a huge feature of the android, and are building their products to take advantage of this. There are automotive engine monitors that will do this today, and won't support iOS because of the lack of SPP.
So you say "all the aviation companies support iPads". That is true, to an extent. Certainly Jeppesen, WingX and others support iPads. WingX also supports Android, and there is a whole site dedicated to Android aviation apps. Flightplan.com, flightaware.com and others also have nice Android apps.
How about form factor. Say you have a big panel, and you want to fill it with tablets. No problem, get a couple 10 in displays, and you are good. How about a small panel, maybe 2 7inchers, and a 4inch for backup. But you say iPads only come in one size, how do they compete? (you might be noticing a pattern).
Then the argument about the enterprise. iPads work great in the enterprise, they sync email and scheduling. Okey doke, but not a 10,000 over eastern Montana they don't. You want to sync with your engine, and maybe your air data computer. That is what matters. If you need to sync with your office, you'll need a data connection to the ground (row44 maybe?). By the way, Androids' sync to email and scheduling just as well.
Licensing and releases, well the android probably will win that. Apple comes along and thinks what is best for iTunes, not your charts. Remember the iOS4 trouble when the iOS would clean up your "old" files for you, thinking they were old movies or songs. That low altitude enroute chart that was 25 days old didn't survive, and you had to scramble to find a sectional or high altitude chart to cover for you. You can vette out the system that works for you, and take or not upgrades for your display.
How about RIM or Windows. Maybe, they will work. I still haven't seen a windows tablet, and the PlayBook is only available in one size. If someone has time, we could work on it together (you want to send me one, I'll play with it, I promise :-). Critical mass is the magic here, are they available, can I get one, and what do I need to develop for it?
The SDK for the iPad and Android seem to cost about the same thing, nothing. Writing for the iPad is in Objective-C. The Android is Java sorta. Both languages are object oriented, with a C base. There are many people in the world who can develop for them, so that wouldn't be a reason to pick one over the other. Apple tends to control the iTunes store, and that is about the only way to deliver apps to the iPad. Android allows others to host and distribute apps, you aren't locked in to the Android market. There are risks getting apps from a non-android or non-apple market, but most are honest, so they work. There are malicious apps in both market places, and they get cleaned up fairly quickly.
For me, I have chosen the Android eco-system because of the openness, or at least appearance of openness. I havn't spent a dime on software, I have a demo cooking, and it'll work with my stuff as I designed it. Your mileage may vary, and I'll listen to any argument.
Keep on soldering.
Friday, March 30, 2012
Another SDR Post
I started putting together the hardware for the thermocouple amplifiers, but quickly realized I didn't have everything I needed. I needed some reasonable sized capacitors (0.47uf 10V or so) and a trimmer resistor. The closest I could find in my collection was a .10uf at 25V or .33uf at 1000V. I thought, crap, for less than a dollar, I should get what I need. That 1000V cap, while close to what I needed, was bigger than the chip. Board real-estate would be a challenge. I know it is just a proof of concept, but I needed something better. I have some surface mount caps, but even those were all over the map, like 47uf, or 100pf, nothing kinda medium.
I was thinking a quick order at Mouser or Digi-Key and I would have what I need by Wednesday. Well, it would take a $25 minimum order, and I'd obsess over what else to buy for 5 days, and I wouldn't get what I need until next week. I had a coincidence happen on Tuesday. Traffic was awful, and I needed to try a different way home. I ended up in Farmers Branch. Tanners Electronics is right there. I thought I am close, maybe they stay open until 6pm. IT was about 4:50pm, and I was close, so I thought I'd go for it.
They are open until 6 Monday through Saturday. I could pop in there and get what I needed. When I got there, I was surprised. They had about the same collection of small capacitors as I did, .33uf at 1000V and some surface mount ones. I did find a couple medium ones, one disk, and one film and a small one, mylar I think. I bought an assortment, at least 2 of each, and a couple trimmer pots, spending all of $3, and I had them.
I haven't had time to do anything with them though. I hope to this weekend.
I've been thinking what a full system might look like. How about the Arduino as the engine controller and monitor. This is for the full FADEC system. Then a USB connection to a central hub, maybe an ARM controller running Linux. Another Arduino running DIY Drone air data computer, and IRS gyro package connected to the central controller over USB. Each Arduino would have their own blue tooth connection for sending to the display computers. Display computers would be Android tablets. I am not sure what the central system would do other than data collection. I guess it should share information, with the two Arduino's. Like putting in a TOGA button, the FADEC would run the engine up for takeoff power, then the autopilot would fly the missed approach procedure. The central computer would have some GPS and mapping software, unless that was outboard also (Android tablet may have that?).
Lots of planning and dreaming.
I said this was an SDR post. Well, here is the SDR info. Suddenly SDR hardware is down to about $20! You can buy USB tuner cards for PC's that have untuned front ends for $15-25 on EBay. There is software available to use them, and they are quite popular. They can tune anything from about 64-1700MHz and should work in almost any mode (even TV, since that is what they are designed for!). Reddit has a hardware compatibility chart.
I ordered one, maybe, I'll have time to play with it. It sounds like it has most of the software written. All I need to do is plug it in and run some code.
I also found the LinuxCNC website. That might be my answer to the 3D printer I've been wanting to work on. Again, when I get some time, I'll take another look at it.
I was thinking a quick order at Mouser or Digi-Key and I would have what I need by Wednesday. Well, it would take a $25 minimum order, and I'd obsess over what else to buy for 5 days, and I wouldn't get what I need until next week. I had a coincidence happen on Tuesday. Traffic was awful, and I needed to try a different way home. I ended up in Farmers Branch. Tanners Electronics is right there. I thought I am close, maybe they stay open until 6pm. IT was about 4:50pm, and I was close, so I thought I'd go for it.
They are open until 6 Monday through Saturday. I could pop in there and get what I needed. When I got there, I was surprised. They had about the same collection of small capacitors as I did, .33uf at 1000V and some surface mount ones. I did find a couple medium ones, one disk, and one film and a small one, mylar I think. I bought an assortment, at least 2 of each, and a couple trimmer pots, spending all of $3, and I had them.
I haven't had time to do anything with them though. I hope to this weekend.
I've been thinking what a full system might look like. How about the Arduino as the engine controller and monitor. This is for the full FADEC system. Then a USB connection to a central hub, maybe an ARM controller running Linux. Another Arduino running DIY Drone air data computer, and IRS gyro package connected to the central controller over USB. Each Arduino would have their own blue tooth connection for sending to the display computers. Display computers would be Android tablets. I am not sure what the central system would do other than data collection. I guess it should share information, with the two Arduino's. Like putting in a TOGA button, the FADEC would run the engine up for takeoff power, then the autopilot would fly the missed approach procedure. The central computer would have some GPS and mapping software, unless that was outboard also (Android tablet may have that?).
Lots of planning and dreaming.
I said this was an SDR post. Well, here is the SDR info. Suddenly SDR hardware is down to about $20! You can buy USB tuner cards for PC's that have untuned front ends for $15-25 on EBay. There is software available to use them, and they are quite popular. They can tune anything from about 64-1700MHz and should work in almost any mode (even TV, since that is what they are designed for!). Reddit has a hardware compatibility chart.
I ordered one, maybe, I'll have time to play with it. It sounds like it has most of the software written. All I need to do is plug it in and run some code.
I also found the LinuxCNC website. That might be my answer to the 3D printer I've been wanting to work on. Again, when I get some time, I'll take another look at it.
Sunday, March 25, 2012
Reeling in Some Scope.
I was getting all excited about ordering all the parts I need to get to the finished design. Well, I realize there is more to it than just firing up Eagle, and laying out the board, ordering it, having a B.O.M. ready and assembling a couple proto boards.
I am needing a good solid proof of concept. Can I really measure C.H.T's and E.G.T's with the simple design, and a multiplexer? Well, lets try it and find out. Otherwise I need to build something different. Will the various analog inputs work with a Tack and other inputs? Well, lets get them other inputs working, and then try a tachometer.
For now, I am going to use at least one of the LTC1050s that I have for the CHT's. I'll just set it up like the example on page 9, the 500degree battery powered temperature sensor. If that is working, with reasonable accuracy, then I'll add a multiplexor in front of that. I'll probably need a different amplifier for the EGTs since they will get to something on the order of 1500degrees.
For the oil and fuel pressure senders, I have something like the The Mitchell 80# sender. This will ground some of the supplied voltage, and we need to measure the current going through the sender. We can do that with a transistor, and some resistors.
I've also got a hall effect current sensor that I want to use. I think it is an Allegro. I got it as a sample a couple years ago. I'll finally get to try that out. That is supposed to handle up to 100Amps with no shunt, all power is available.
The one worry I have is about board layout. I may have to look into getting another board, and modifying it (electronically). That is be beauty of open source, people share, and allow fixing things. People share, and make things available for the rest of us.
Anyway, you can see I am getting more active. A little success will do that for a guy.
I am needing a good solid proof of concept. Can I really measure C.H.T's and E.G.T's with the simple design, and a multiplexer? Well, lets try it and find out. Otherwise I need to build something different. Will the various analog inputs work with a Tack and other inputs? Well, lets get them other inputs working, and then try a tachometer.
For now, I am going to use at least one of the LTC1050s that I have for the CHT's. I'll just set it up like the example on page 9, the 500degree battery powered temperature sensor. If that is working, with reasonable accuracy, then I'll add a multiplexor in front of that. I'll probably need a different amplifier for the EGTs since they will get to something on the order of 1500degrees.
For the oil and fuel pressure senders, I have something like the The Mitchell 80# sender. This will ground some of the supplied voltage, and we need to measure the current going through the sender. We can do that with a transistor, and some resistors.
I've also got a hall effect current sensor that I want to use. I think it is an Allegro. I got it as a sample a couple years ago. I'll finally get to try that out. That is supposed to handle up to 100Amps with no shunt, all power is available.
The one worry I have is about board layout. I may have to look into getting another board, and modifying it (electronically). That is be beauty of open source, people share, and allow fixing things. People share, and make things available for the rest of us.
Anyway, you can see I am getting more active. A little success will do that for a guy.
Thursday, March 22, 2012
Simple Round Gauge
So for grins, I started a simple round gauge for the thing. It has variable radius, and location. I can instantiate multiple of them, and I can override it to make it a different shape or something. The beauty of and object oriented language. Actually I should design this better, make an interface, and multiple implementations. Graphs can be fun, and round gauges come in all sorts of shapes and sizes.
Some round gauges are 135 degrees and start at the bottom (speedometer or tachometer are examples), others the left and still others the right. Some round gauges are only 90 degrees and start left or right (fuel gauges are like that). Implementing multiple of these could be quick and simple, and useful.
Hey how about that, I was able to upload a picture. The have to be not much bigger than this to work. Sorry.
On the right is my Arduino stack, the main board is on the bottom, then a prototyping shield with my home made pass through connectors, and then the top board is the bluetooth board.
Looking on the screen (maybe it is too small), in the upper left, you can see a round gauge. Yes, that is displaying the temperature right now in the room I am in! That transistor thing sticking up on the prototype shield is the LM34 sensor. The USB connector on the Arduino is only there to power the board. I am not doing anything tricky.
Now we are cooking, more sensors, more graphs, and we are on our way. I'll try to keep things documented. So far I haven't veered too far from the original sensor graph code, but it is what it is. You could probably get where I am using these notes and and getting the original sensor graph code.
Good Luck.
Some round gauges are 135 degrees and start at the bottom (speedometer or tachometer are examples), others the left and still others the right. Some round gauges are only 90 degrees and start left or right (fuel gauges are like that). Implementing multiple of these could be quick and simple, and useful.
On the right is my Arduino stack, the main board is on the bottom, then a prototyping shield with my home made pass through connectors, and then the top board is the bluetooth board.
Looking on the screen (maybe it is too small), in the upper left, you can see a round gauge. Yes, that is displaying the temperature right now in the room I am in! That transistor thing sticking up on the prototype shield is the LM34 sensor. The USB connector on the Arduino is only there to power the board. I am not doing anything tricky.
Now we are cooking, more sensors, more graphs, and we are on our way. I'll try to keep things documented. So far I haven't veered too far from the original sensor graph code, but it is what it is. You could probably get where I am using these notes and and getting the original sensor graph code.
Good Luck.
Wednesday, March 21, 2012
Thinking and Planning
After last night, I almost didn't go to bed. I was pretty excited. Almost a year of frustrations and now it is showing progress. Cool, well sorta. I still have a bit to do. The sensor graph just barely shows what is possible.
The pictures never showed up, I'll take another crack at it here:
(I don't get it.. I've uploaded them before?)
I was thinking of being really creative with OpenGL gauges, I could make 'em look just like the analog gauges in the plane, with 3d moving needles and all. Of course what would be the point, I already have that, and they work. No, I want something better. I was thinking the non-linear guages (the ones that show a lot of detail around the normal range and less detail out of normal. And again I can get all fancy, with moving needles and such. I think for now though, I'll try something simple, get that working, and comeback and make it pretty.
I need to maintain the MVC (model view controller) pattern. The phone or tablet screen is the view/controller and the Arduino is the model. All the data comes from the Arduino, the screen will allow some control from the screen, if I move toward a FADEC system. For now, this will be monitor only. (it has all that potential! I should use it ;-).
I need to dig into the whole GUI part, and understand what Android can and can't do graphically. I need to get more hardware hooked up.
More when I get there.
The pictures never showed up, I'll take another crack at it here:
(I don't get it.. I've uploaded them before?)
I was thinking of being really creative with OpenGL gauges, I could make 'em look just like the analog gauges in the plane, with 3d moving needles and all. Of course what would be the point, I already have that, and they work. No, I want something better. I was thinking the non-linear guages (the ones that show a lot of detail around the normal range and less detail out of normal. And again I can get all fancy, with moving needles and such. I think for now though, I'll try something simple, get that working, and comeback and make it pretty.
I need to maintain the MVC (model view controller) pattern. The phone or tablet screen is the view/controller and the Arduino is the model. All the data comes from the Arduino, the screen will allow some control from the screen, if I move toward a FADEC system. For now, this will be monitor only. (it has all that potential! I should use it ;-).
I need to dig into the whole GUI part, and understand what Android can and can't do graphically. I need to get more hardware hooked up.
More when I get there.
Tuesday, March 20, 2012
Now we're cooking!
Like I said, I thought I'd try installing the Android Development kit on the desktop. It took several hours, downloading JDK, Eclipse and the the SDK. Then there were all the other devices (I forget what they are called, anyway the modules for the various versions of stuff). I finally was able to see sensor graph working in the emulator about 8PM Sunday evening, but I was encouraged. Before I disappointed myself, I shut everything down. My family had just gotten home, and I didn't want to nerd out on them.
So tonight I thought I'd try it, and see how successful I was. A couple quick lessons in uploading apps to the Android (I needed the Sensor Graph app to be running). I needed to set the Bluetooth address in the application, so I needed to plug in the Arduino and run the Amarino app to see what the address is. Ok, it is 00:11:04:15:10:87, and I put that in the SensorGraph.java file in eclipse, ran compile, uploaded the .apk file to the phone, then ran the app installer on the phone. It connected.
I forgot a crucial step. The Arduino is still probably running my quad stepper app. I need the Sensor Graph app running on the phone too. I open the Arduino app and it wants install a software upgrade. I figure yea sure why not. Well, once it was installed, I remember why, the lib and sketches aren't there. Fortunately it didn't overwrite my original stuff, so I went back to the 0-22 version, and everything was there. Load library Hello Android and get my sensor graph running. Still nothing.
I open the serial monitor, and all I see is gibberish. Dang, baud rate is wrong. I change the baudrate to 9600, and I see "179 172 178 176 174" scrolling across the Arduino serial monitor screen. Cool! I had connected an LM34 temperature sensor to pin 15. It is doing something, but I should try something faster. There is some complicated instructions on the iTread studio stackable bluetooth shield web page about sending the AT commands to change the baud rate. I can't get it to work, but will be happy if 9600 baud works. I change the sketch to use 9600 baud, and upload that, I switch the switch from FT232 to board and viola! something is happening.
Well I get things looking good on the screen, I see the same numbers and the graph is a little jiggly, but mostly straight across the screen. I put my finger on the sensor, and it goes up. Thinking about how this works, and what the data sheet says, 10mv per degree F. What is the full range of a sensor (12bit or 8bit?). I got some research to do.
For those who might not believe, here are some crummy pictures (very hard to read, and big too).
So tonight I thought I'd try it, and see how successful I was. A couple quick lessons in uploading apps to the Android (I needed the Sensor Graph app to be running). I needed to set the Bluetooth address in the application, so I needed to plug in the Arduino and run the Amarino app to see what the address is. Ok, it is 00:11:04:15:10:87, and I put that in the SensorGraph.java file in eclipse, ran compile, uploaded the .apk file to the phone, then ran the app installer on the phone. It connected.
I forgot a crucial step. The Arduino is still probably running my quad stepper app. I need the Sensor Graph app running on the phone too. I open the Arduino app and it wants install a software upgrade. I figure yea sure why not. Well, once it was installed, I remember why, the lib and sketches aren't there. Fortunately it didn't overwrite my original stuff, so I went back to the 0-22 version, and everything was there. Load library Hello Android and get my sensor graph running. Still nothing.
I open the serial monitor, and all I see is gibberish. Dang, baud rate is wrong. I change the baudrate to 9600, and I see "179 172 178 176 174" scrolling across the Arduino serial monitor screen. Cool! I had connected an LM34 temperature sensor to pin 15. It is doing something, but I should try something faster. There is some complicated instructions on the iTread studio stackable bluetooth shield web page about sending the AT commands to change the baud rate. I can't get it to work, but will be happy if 9600 baud works. I change the sketch to use 9600 baud, and upload that, I switch the switch from FT232 to board and viola! something is happening.
Well I get things looking good on the screen, I see the same numbers and the graph is a little jiggly, but mostly straight across the screen. I put my finger on the sensor, and it goes up. Thinking about how this works, and what the data sheet says, 10mv per degree F. What is the full range of a sensor (12bit or 8bit?). I got some research to do.
For those who might not believe, here are some crummy pictures (very hard to read, and big too).
Subscribe to:
Posts (Atom)