DIY PROMDo It Yourself PROM chip burning help. No PROM begging. No PROMs for sale. No commercial exchange. Not a referral service.
Welcome to ThirdGen.org!
Welcome to ThirdGen.org.
You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, at no cost, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, join the ThirdGen.org community today!
To be clear, it's not overhead added to the serial stream that slows it up (under the covers the serial driver is nearly identical), its the fact that NT 4 uses an emulated DOS mode. Your serial stream is not that blazingly fast.
If you'd like to send me details of your protocol offline, I may be willing to, over time, write a fast and efficient Windows compatible program without the bloat, or perhaps integrate support into TunerPro (I'm completely re-writing my ALDL engine and logging controls and mechanisms anyhow, so now's the time).
As far as the HUD goes - you have Labview to blame. =(
Let me know, Bob.
This ad is not displayed to registered members. Register your free account today and become a member on ThirdGen!
Sponsored Links
Registered users do not see this ad. Click here to register for free!
Originally posted by Mangus To be clear, it's not overhead added to the serial stream that slows it up (under the covers the serial driver is nearly identical), its the fact that NT 4 uses an emulated DOS mode. Your serial stream is not that blazingly fast.
If you'd like to send me details of your protocol offline, I may be willing to, over time, write a fast and efficient Windows compatible program without the bloat, or perhaps integrate support into TunerPro (I'm completely re-writing my ALDL engine and logging controls and mechanisms anyhow, so now's the time).
As far as the HUD goes - you have Labview to blame. =(
Let me know, Bob.
1. How would emulated DOS mode cause the slow down. Can you be more specific?
2. The serial stream is rather fast, not blazing to the serial ports limits but when you have to crunch the numbers and not just write them to disk it can start to show some cpu load... most of it comes from the display. Crappy graphics cards like those found in laptops seem to be the issue. I tested HUD on another machine tonight. A p2 450mhz 128mb ram Geforce MX... LOW cpu load. Lower than my p4 2.4Ghz 512mb ram SiS650m laptop.
3. It would be great if you could support this in TunerPro
4. How do you know we have LabView to blame? Why couldn't it just be the programmer ?
What's been your experience as far as the amount of driving and auto tune. How long before auto tune has pretty much locked in to a tune?
I can't give you a number nore can I give you an estimate. All I can say is that with a warmed up engine it shouldn't take long. The major factor is how many cells you can hit. Using the brakes, holding gears, slow throttle movements to quick (not fast) that'll get certain cells without triggering AE.
When you get the beta software try it out. Have somebody site in the passenger seat with the software open to the "learned VE" tab. Watch their jaw drop, then keep your eyes on the road .
Originally posted by JPrevost 1. How would emulated DOS mode cause the slow down. Can you be more specific?
2. The serial stream is rather fast, not blazing to the serial ports limits but when you have to crunch the numbers and not just write them to disk it can start to show some cpu load... most of it comes from the display. Crappy graphics cards like those found in laptops seem to be the issue. I tested HUD on another machine tonight. A p2 450mhz 128mb ram Geforce MX... LOW cpu load. Lower than my p4 2.4Ghz 512mb ram SiS650m laptop.
3. It would be great if you could support this in TunerPro
4. How do you know we have LabView to blame? Why couldn't it just be the programmer ?
1. Code hand-optimized for DOS on a 386 just doesn't work the same when you change the platform from underneath it (or over it in the case of emulation). It's like saying, "My code is optimized to run great on a PC, but for some reason it just doesn't perform the same when I run it on a mac running virtual PC."
2. Display = Labview. A 100mhz PC can crunch the numbers you're talking about hundreds of times faster than the serial speed you're using.
3. Cool.
4. Maybe both then? =) Labview is worse than .NET in terms of bloat. I suspect you knew that was coming, though, but that you chose Labview because its easy for you to program for and "pretty", right?
In any case, sounds like you and Bob have been working hard and its beginning to pay off! Can't wait to see this change the world!
Originally posted by Mangus To be clear, it's not overhead added to the serial stream that slows it up (under the covers the serial driver is nearly identical), its the fact that NT 4 uses an emulated DOS mode. Your serial stream is not that blazingly fast.
I forgot about that, when running on NT4.0 there is a virtual driver for the COM ports. IIRC (its been awhile), the virtual driver intercepts every access to the hardware and handles it. This is because a program is not allowed to access any hardware directly (protected by the OS). So this adds overhead for a program that goes to the serial ports.
Under Windows 95 and 98 direct access is allowed. How does XP handle this? It is derived from NT, wonder it they loosened up the protection. . .
So, all in all, if not running under NT the HUD will be able to handle the 57Kb data stream without issue.
Originally posted by RBob How does XP handle this? It is derived from NT, wonder it they loosened up the protection. . .
XP works the same as NT (and Windows 2000).
It should not be difficult to write a command line application that processes the data that you need processed at the speed you need processed. What languages are you familiar with? I can walk you through (or outline) most of it for you to get you started.
Originally posted by Mangus 1. Code hand-optimized for DOS on a 386 just doesn't work the same when you change the platform from underneath it (or over it in the case of emulation). It's like saying, "My code is optimized to run great on a PC, but for some reason it just doesn't perform the same when I run it on a mac running virtual PC."
2. Display = Labview. A 100mhz PC can crunch the numbers you're talking about hundreds of times faster than the serial speed you're using.
3. Cool.
4. Maybe both then? =) Labview is worse than .NET in terms of bloat. I suspect you knew that was coming, though, but that you chose Labview because its easy for you to program for and "pretty", right?
In any case, sounds like you and Bob have been working hard and its beginning to pay off! Can't wait to see this change the world!
1. Makes sense although what a royal PITA to not be able to directly access your OWN hardware. Was it there because some hackers might have been able to destroy your hardware if they got access to your system? In either case... physical firewall equipment is too cheap not to have so give me back my direct access Mr.Gates.
2. Yes, there is plenty of cpu power left over WHEN you have a decent video card. It was worse when I didn't use the "classical" gauges which had gradients all over the place.
3. Yes, it would be.
4. Got proof? LabView is ment for very high speed data aq. I can't see how it would be full of bloat. LabView is easy to program but more over it's rather powerful right out of the box. The code is easier to follow then sequential (for me at least) and no, it's not just pretty. Infact it can be down right ugly in some areas. The benifit of LabView again is it's flow chart programming design. When you compile things get rather small. The main program is less than 900 KB. That's approx twice that of WinALDL and about 200 KB larger than TunerProRT. Of course none of this includes the run-time lib or misc lib's. Did I mention LabView runs on Mac's... or at least I'm told it does. Cross platform compatible = bloat? maybe?
Originally posted by Mangus XP works the same as NT (and Windows 2000).
It should not be difficult to write a command line application that processes the data that you need processed at the speed you need processed. What languages are you familiar with? I can walk you through (or outline) most of it for you to get you started.
Hmm, not surprised that it is the same. OK, thanks.
As for command line app's, it is just that it is a Windows world. There really isn't too many folks around that even know what a DOS window is. Originally I wasn't going to include the HDS program (the DOS data log program). With it able to log data on just about any laptop, even Smithsonian grade I decided to include it.
I have a bunch of DOS based programs that I use to crunch Lockers data. One for VE tuning (based on either BLM or WB data), another for spark advance tuning (based on knock retard), another that maps AFR, then another that displays MPG, distance traveled, and RPM in large font in real time.
Then another program that breaks down the Lockers data into several different files. Each file contains data relative to a specific area. The data is in tabular format and is easily opened in Notepad for perusal. Then chunks can be pasted into Excel for graphing.
I could recompile these as WIN32 Command Line app's, but they would still be a command line app. Maybe a Windows wrapper would be the way to go. Combine the source for the various functionality, add some menus, and let the user at it.
However, Jon's HUD provides a good tool for datalogging, playback, VE learning, and graphing. It is Windows based, point and click, and user friendly. Right now it seems the real killer is the serial port handling in Windows. That is the part that is slowing everything down.
Originally posted by JPrevost 1. Makes sense although what a royal PITA to not be able to directly access your OWN hardware. Was it there because some hackers might have been able to destroy your hardware if they got access to your system? In either case... physical firewall equipment is too cheap not to have so give me back my direct access Mr.Gates.
The reason an application program is not allowed to access the hardware is to secure the OS. This prevents errant programs from taking the machine down or locking it up, or trashing the HDD, or (insert any ugly situation). BTDT, including trashing the HDD while developing on DOS based machines.
I haven't written a kernal level driver in a number of years. But with the streaming data that the EBL creates, it may be the way to go. We don't see 100Mb Ethernet not being able to keep up.
Maybe the USB adaptor and driver is allowing faster data rates with less overhead?
Originally posted by JPrevost 4. Got proof? LabView is ment for very high speed data aq. I can't see how it would be full of bloat. LabView is easy to program but more over it's rather powerful right out of the box. The code is easier to follow then sequential (for me at least) and no, it's not just pretty. Infact it can be down right ugly in some areas. The benifit of LabView again is it's flow chart programming design. When you compile things get rather small. The main program is less than 900 KB. That's approx twice that of WinALDL and about 200 KB larger than TunerProRT. Of course none of this includes the run-time lib or misc lib's. Did I mention LabView runs on Mac's... or at least I'm told it does. Cross platform compatible = bloat? maybe?
I'm not talking about the acquisition side of things, I'm talking about the UI side (which is really why you're using it - data acquisition at the level you're doing isn't a good reason to use Labview in my opinion. The UI is). And the UI is the proof. All that UI comes down to code! You're seeing the hit w/ the video card requirement.
In addition, the runtime is what I'd call bloat. It's an external requirement that many people aren't going to be able to run.
Again, not trying to make stink here. All this stuff seems pretty well baked and ready. You're doing good stuff. Keep it up.
Originally posted by RBob As for command line app's, it is just that it is a Windows world. There really isn't too many folks around that even know what a DOS window is. Originally I wasn't going to include the HDS program (the DOS data log program). With it able to log data on just about any laptop, even Smithsonian grade I decided to include it.
Note that command line != DOS. You (or I) can write a command line app that will run in both DOS and at the windows command line.
So, with that said, the trick is compiling in such a way that the applicaiton is not dependent on DOS.
Originally posted by RBob Right now it seems the real killer is the serial port handling in Windows. That is the part that is slowing everything down.
Sorry for all the back and forth, but I guarantee you that the serial port handling isn't what's slowing things down.
I regularly pull data from the port and process it at (breath here) 921 kbaud (serial). Again, that's nothing to even a really slow (in modern terms, a 100 mhz) CPU.
You're probably doing the right thing for your product in the end, though. Do what makes the most sense given your user scenarios.
Originally posted by Mangus Note that command line != DOS. You (or I) can write a command line app that will run in both DOS and at the windows command line.
So, with that said, the trick is compiling in such a way that the applicaiton is not dependent on DOS.
A WIN32 Console Application (not a WIN32 Command Line application as I previously posted). Same page now?
Originally posted by Mangus I'm not talking about the acquisition side of things, I'm talking about the UI side (which is really why you're using it - data acquisition at the level you're doing isn't a good reason to use Labview in my opinion. The UI is). And the UI is the proof. All that UI comes down to code! You're seeing the hit w/ the video card requirement.
In addition, the runtime is what I'd call bloat. It's an external requirement that many people aren't going to be able to run.
Again, not trying to make stink here. All this stuff seems pretty well baked and ready. You're doing good stuff. Keep it up.
The run-time is included in the install and it's a free download from Ni so I don't consider it something people aren't going to be able to run. Or am I reading it wrong?
I'd say yes, there is some bloat in the application but having programmed in several languages I find LabView the easiest to upgrade and add too. As in I can drag and drop with the mouse what would take a seq program language several lines of codes AND clicks! Makes my life easier seeing as this isn't my full time job .
I already have a windows datalogging only program done but if you guys want to make your own, go for it . A little competition to see who's is the most efficient would be fun.
If you need some help or an extra set of eyes to look at some of the problem areas with LabVIEW I would be more then happy. I have been using it since Version 3.11 in 1995/1996 and I am currently upgrading all my test code at work to Version 8.
Which version did you do HUD in? I think either 7.0 or 7.1.1 requires 2000/Xp. I know ME, 98se/98/98 are not supported.. not sure about NT though
__________________ -=Jeff=- 1989 Corvette CoupeFOR SALE 1990 ZR-1 (New Project)
I played with some LabView a bit back around 96 or so, and then again the last few years for some industrial R&D stuff. I probably wouldn't be much help, as I'd become more dependent on my skilled technicians for things that I didn't NEED to learn, but I do recall that when you start having some significant refresh rates on the fancier graphic renderings, it can bring things to the knees.
One trick we carried out was having the data logging actually occur at a higher rate than what was actually the refresh rate of the graphical rendering. At 4 Hz or so, the user doesn't really notice any slow-down. That helped. Would help folks with slower PCs, maybe they could select the graphic refresh rate?
Might want to keep an eye on logging-to-disk activity also. I remember having some significant slowdowns with the older machines due to this factor, and being able to counter it by buffering up packets in RAM and dumping them block-wise to the HD as was reasonable.
Again, this is very nice work. Good to see y'all getting after it!
Originally posted by Craig Moates Sweet. Really coming along!
. . .
One trick we carried out was having the data logging actually occur at a higher rate than what was actually the refresh rate of the graphical rendering. At 4 Hz or so, the user doesn't really notice any slow-down. That helped. Would help folks with slower PCs, maybe they could select the graphic refresh rate?
. . .
Again, this is very nice work. Good to see y'all getting after it!
Thank you for the kind words of encouragement. I like the idea of slowing down the refresh rate. This could easily be done and would help speed things up.
Originally posted by Craig Moates Sweet. Really coming along!
I played with some LabView a bit back around 96 or so, and then again the last few years for some industrial R&D stuff. I probably wouldn't be much help, as I'd become more dependent on my skilled technicians for things that I didn't NEED to learn, but I do recall that when you start having some significant refresh rates on the fancier graphic renderings, it can bring things to the knees.
One trick we carried out was having the data logging actually occur at a higher rate than what was actually the refresh rate of the graphical rendering. At 4 Hz or so, the user doesn't really notice any slow-down. That helped. Would help folks with slower PCs, maybe they could select the graphic refresh rate?
Might want to keep an eye on logging-to-disk activity also. I remember having some significant slowdowns with the older machines due to this factor, and being able to counter it by buffering up packets in RAM and dumping them block-wise to the HD as was reasonable.
Again, this is very nice work. Good to see y'all getting after it!
I've already got the buffer to RAM then dump to disk adjustable for the user between .1-10 minute intervals. Keeps the HD activity down like you said which can cause some slow downs on slower drives.
I think I might have the display do ever other packet and see how that does for the user.
I already slowed down the 3D chart updating from 17Hz to 1.7Hz and that made a huge difference.
It's getting better.... again, not my full time job, not my part time job either so I'm doing what I can.
For those doing a piggyback application, Casper's Electroncis, has the 36/24 pin ecm side connector, and matching PCB, so that you can solder the connector to the board, and then solder the wires to the board, so that things are more robust, then just soldering the wires to a header, and saves the time of trying to desolder a header from another ecm. Their number is (847) 247-0484. You want to talk to John on these, since it's an item rarely sold anymore.
Originally posted by Mangus You can set the FIFO buffers programmatically.
Dimented - I've never seen nor heard of such issues with the dash or ALDL monitors. The only thing I can think of is that your graphics chip in your laptop doesn't support bitblt'ing, which, if that's true, its time to get a new laptop, dude. =)
Those two controls (the dash and monitor controls) draw using GDI - the most common method for 2D drawing across all the Windows operating systems. Nothing special there (except for bitblt'ing to reduce flicker, but I didn't think there were any chips in at least the last 10+ years that don't support that. Go figure!).
K. Back to the topic at-hand.
My PII-333MHZ laptop has the same problems with the ALDL dash. Sometimes it comes up blank, you have to close TP and re-open then the ALDL dash comes up fine. Sometimes the ALDL dash title is displayed BUT no numbers are shown. You have to close and re-open TP.
The ALDL datalog and regular ALDL display works fine most of the time. Sometimes the ALDL display values won't update (but it is bitblitting because you can see the screen flashing). All the values read as zeros. If you close the ALDL display and re-open a few times, it will start working.
Originally posted by junkcltr My PII-333MHZ laptop has the same problems with the ALDL dash. Sometimes it comes up blank, you have to close TP and re-open then the ALDL dash comes up fine. Sometimes the ALDL dash title is displayed BUT no numbers are shown. You have to close and re-open TP.
The ALDL datalog and regular ALDL display works fine most of the time. Sometimes the ALDL display values won't update (but it is bitblitting because you can see the screen flashing). All the values read as zeros. If you close the ALDL display and re-open a few times, it will start working.
If the screen is flashing, it's not bitblt'ing. Which also explains the issue you're seeing. =(
Sounds like you two might have the same computer. Not much I can do about it, unfortunately, other than remove the bitblt'ing, which would penalize everyone else. I'll put some thought into other potential solutions, though. Wish I had a computer here that had the problem. Makes it 10x easier to work around.
Edit: I just added a check (for the next build soon to be out) that will inform you if your computer doesn't support bitblt. At least this will give a definitive answer as to what the issue is.
Beta's are going well. One guy has been running the EBL for the past week. Really likes it, better performance, good logging, and the VE autotune is working for him. Another guy is snowed in but has provided valuable feedback on the documentation. Another is in progress getting the EBL ECM installed.
All in all, we need some additional documention (which I am currently working on) for hookup, general info (such as which E/Flash PROM to use), and a 'set these parameters first' for the bin.
The HUD is being worked on: the VE autotune saving to a BIN (currently need to hand enter the new values), along with some data exporting features.
I'm thinking that with these changes EBL will be ready for release. I'd like to get a web site up first, but that may not happen. I have a bunch of pictures for a hookup guide and still need some for board install.
I know I keep saying soon, at this point I don't want to say when. However, it won't be much longer. I appreciate the patience everyone is showing.
Originally posted by robertfrank and once again , any updates oh masters of tbi pcm wizardry? lol
Ahem. Even just swapping to the EBL with no other calibration changes, you will be thrilled with what this does for the performance of your motor. At least, that's what I've "heard".
Originally posted by Fast355 I know of a certain roller "cammed" 305 that runs much better with it.
Fast,
There's also an unsubstantiated rumor of a stock block Xfire Vette that already runs low 13's now using EBL with the Moates Ostrich and getting MPG data on its Digital Dash too. That would be awesome IF it were true.
Last edited by Dominic Sorresso; 12-28-2005 at 05:27 PM.
Originally posted by RBob I have all cost's except ship on just the EBL board (self install). I can ship that USPS easy enough and less expensive, but tracking is not as good.
For anyone that wants cost's please PM me. It is the same for everyone, and reasonable.
I would like to give an update and let everyone know what is going on. With the first of the new year we will be accepting orders and shipping product. Jon and I have been busy adding features to the HUD, building/testing boards, enhancing the documentation, and adding to the EBL TBI code (can you say '2-bar MAP support').
Our goal is to release a product that will work for you with the minimum of issues.
The beta testers have provided valuable feedback on the Embedded Lockers system: doc's, wiring, ECU, code, HUD, etc. I thank them for their effort.
With the new year the EBL will be shipping. Incremental upgrades will also be available. Thanks again for your patience.
My factory chip is a 16136965, I had planned on going to the 28 pin flash chips via G2 from Moates, but if that board is compatible with this chip (you kept going on about 122XXXXX) you've got me sold. If it isn't compatible how do I make it so?
Another query for the '6965 as I also have one in my 93 9C1.
I just spent a day or two reading up on this thread and I am thrilled with this development. You won't see this kind of work in the Ford or Mopar world, that's for sure.
Since I'm also a regular user of Tunercat, I was hoping for a TDF, which would also presumably allow me to do RT TC when I get around to upgrading my TC software and buying the hardware (leaning toward the Xtronics Romulator). Thoughts on that? I find TC to be fairly robust, bug-free commercial-grade software. It sounds like Tunerpro is still in its infancy.
__________________ Kevin Moore
1993 Caprice 9C1
L05 TBI, 256k, Dual electric fans, PVC intake w/ NAPA Gold FIL-6440 (!K&N), LT1 manifolds & cats, Dynomax catback, SS spoiler, rear discs, Detroit TrueTrac.
95 Camaro Z28, black, t-tops, leather, T56, 173k. PVC intake w/ K&N. Dynomax Ultraflo SS muffler. SOLD
95 Cadillac Fleetwood Brougham. 92k, daily driver.
? 
. 
I decided to include it.
