http://www.linxtechnologies.com/products/rf-modules/sg-series-gps-receiver-modules/
http://www.linxtechnologies.com/products/rf-modules/sr-series-gps-receiver-modules/

http://www.linxtechnologies.com/products/evaluation-kits-master-development-systems/

Robin F Berglund

Henry Nee got Ubuntu 10.04 working on my EeePC 1000. This added
about 1000% to it's functionality. I now have a net book with
a 40 gig solid state drive and 8 hour battery life.


Henry also came up with a brilliant idea today for an EFI system.
He suggested saving the mixture maps in spread sheet files on the
home computer and up loading it to the EFI system in the airplane.
This means people can share mixture maps and one can save all the
maps one might develop and go back if necessary. It is also extremely
easy to edit the mixture map. It will work with any computer capable
of running a spread sheet program.

Brilliant idea Henry. Thanks for sharing that idea.
Now all we need is an EFI system with a USB port.
Tracy's computer is almost there with his EM serial interface.

BTW Henry, I upgraded the Dram with to 2 gig from one gig on the way
home at Fry's. 2 gig is all the EeePC 1000 supports.


Paul Lamar


Paul,

Thank you for spending time looking over the partially built Long EZ
for me. I am happy to say that I have a goal to eventually build and
fly my own. Before I can do anything, I will have to study over all
the material collected by the previous owner, and move the fuse and
wings back to my garage. Looks like I will have to plan for an
official start in 2012.

As I mentioned to you earlier, I think the problem with liability is
not just multiple systems. It is important to have a back up, but more
important to have a self healing solution.

Even though I have not yet started to build my own, I have been
reading as much information as I can find about EFI, and  ECUs, among
other things. I notice two major issues with current systems. 1.
Reliability of Fuel map data, and ease of entry, and
2. log file and related information. I believe that a log file of the
ECU should be created, allowing quick elimination of sensor problems.

On 1, it can be done by adding a second copy of the fuel map, and
adding checksum to the working copy to guarantee the automatic
detection of the errors, and the automatic fail over to a correct one.

On 2, the log file, assuming it contains crank sensor trigger time,
will allow one to easily spot a discontinuity and pin point the
gremlins.

I think a processor based ECU with the features above, and a
spreadsheet as fuel map manipulation and storage tool, would make a
very reliable ECU system.

At this point I am thinking about taking a PIC based system, adding
the interface and the above features to create a workable ECU for
Rotary Engine.

I wonder if anyone might be interested in a self healing ECU. If so, I
would spend time on developing such a unit right away, but someone
else would have to be willing to test the design on their engine. I
will not be able to do that because I don not yet have any engine.

Henry


Take a look at this company Henry. The compiled basic is very fast.
http://www.zbasic.net/

The output being comma delimited would load directly into a spread sheet.

I would love it and anybody could learn to understand the code.
If you need something I could order it and ship it to you.

Paul Lamar

public x as long
public val as byte
Public y as byte
Public hour as byte
Public minute as byte
Public seconds as single
Public pin88 as byte 

Sub Main()
Register.DDRH = &H00  ' set the direction
Register.PORTH = &H00 ' turn off pullups

Call PutPin(87, ZXOutputHigh)
Call PutPin(89, ZXOutputHigh)
Call PutPin(86, ZXOutputHigh)   'enable

for x = 1 to 50000000
pin88 = Getpin(88)
'debug.print " pin 88 = " & pin88
If pin88 = 0 then  
Call getval
end if
next
End Sub

Sub getval ()
Call PutPin(86, ZXOutputLow)   'disble
Call GetTime(hour, minute, seconds)
debug.print hour;
debug.print " " & Minute;
debug.print " " & seconds;
debug.print " x = " & x
val = Register.PinH
debug.print "val = " & val
val = Register.PinH
'debug.print "val = " & val 
Call PutPin(89, ZXOutputLow)    'reset latch low does it
Call PutPin(89, ZXOutputHigh)  '
Call PutPin(87, ZXOutputHigh)  'reset count 
Call PutPin(87, ZXOutputLow)     'reset
Call PutPin(86, ZXOutputHigh)   'enable

end sub