EvoScan v2.6 And New EvoScan GPS/Logger/Reflashing Touchscreen Review
#1531
Now that I got EvoScan 2.7 working and mode 23 enabled and logging (though I still cannot get the pc gauge display to work)I dug out the EvoScan gps that I put away back when I was still using AP and found out I needed Mode 23 (not compatable with AP) So I have no manual (did it come with one?), I hook it up with a Y cable to the included 5 volt power supply and my OP2 cable but I continue to get The following message “No Cable Conn. Or No Pwr. Check your cables or reset off/on, try again. Datalogger ended.” I have tried to plug in to my PC and read what if anything is accessible but my PC will not recognize the GPS Nothing!
2010 MR-T (SST)
Stock clutch packs
OEM DiaQueen SST fluid
SSP trans Deep Sump
SSP Front mount trans cooler
OEM intake w/dropin
CBRD BBX full Turbo
AMS DP
RRE Rally test pipe
MXP II CBE
DP 1000 injectors
BlaqOps single pump
WORKS tune using OP (cleaned up by Bryan)
Green relay (yeah that’s it, it MUST be a faulty fuel pump relay!)
2010 MR-T (SST)
Stock clutch packs
OEM DiaQueen SST fluid
SSP trans Deep Sump
SSP Front mount trans cooler
OEM intake w/dropin
CBRD BBX full Turbo
AMS DP
RRE Rally test pipe
MXP II CBE
DP 1000 injectors
BlaqOps single pump
WORKS tune using OP (cleaned up by Bryan)
Green relay (yeah that’s it, it MUST be a faulty fuel pump relay!)
#1532
Evolving Member
Oh and of course this is assuming you have selected the right cable in evoscan settings.
As for plugging it into the PC .. yeah no joy there. Remove the SD card and plug that into a card reader.
#1533
I had this exact problem. *Solution: do not plug the openport into the GPS unit until AFTER you have loaded EvoScan. *Seems that there is a driver issue if you plug it in before. *Oh yeah and completely shut down the unit, reboot it, then load evoscan. *IIRC once you plug the cable into the unit before starting evoscan the "damage" is done until you reboot the unit. *Though there is a chance I'm wrong on that, I was trying a LOT of combinations to get it to work.
Oh and of course this is assuming you have selected the right cable in evoscan settings.
As for plugging it into the PC .. yeah no joy there. *Remove the SD card and plug that into a card reader.
Oh and of course this is assuming you have selected the right cable in evoscan settings.
As for plugging it into the PC .. yeah no joy there. *Remove the SD card and plug that into a card reader.
You say "...assuming**you have selected the right cable in evoscan settings" I click on EvoScan settings and get a menu of items but not show a choice of cable connections.
#1535
#1538
.I think I have tried all the suggestions multiple times. O.K. Let make this simple: I installed 2.2 beta, I reset the gps plus turn off and on, plug in the 5 vt pwr supply into the "y" cable, start EvoScan on the gps, make sure the red power light is on, THEN I plug the "y" cable into the op2 cable and a blank box pops up asking for me to enter a "com port" but there is no way I can figure to enter the name of a com port even if I knew what to enter. If I click ok on the blank box the box comes back, if I click it closed ("x") I get the massage "no op2 cable or power" in the big box on the upper right of the EvoScan screen. What am I doing wrong? Help please.
#1539
Okay, let's go back to basics then work up from there.
Does the GPS work correctly or sit spinning its wheels trying forever to access satellites instead? If it works then the com port is established correctly AFAIK. Don't worry about the Evo side of displaying stuff until the GPS is working normally first.
Regards,
Bill
Does the GPS work correctly or sit spinning its wheels trying forever to access satellites instead? If it works then the com port is established correctly AFAIK. Don't worry about the Evo side of displaying stuff until the GPS is working normally first.
Regards,
Bill
#1541
Okay, let's go back to basics then work up from there.
Does the GPS work correctly or sit spinning its wheels trying forever to access satellites instead? If it works then the com port is established correctly AFAIK. Don't worry about the Evo side of displaying stuff until the GPS is working normally first.
Regards,
Bill
Does the GPS work correctly or sit spinning its wheels trying forever to access satellites instead? If it works then the com port is established correctly AFAIK. Don't worry about the Evo side of displaying stuff until the GPS is working normally first.
Regards,
Bill
#1545
Evolved Member
iTrader: (1)
A few questions....
First it appears this is largely a beta app since people are constantly having minor "onesy-twosy" type issues. Am I correct here? I understand some people tolerate crashes and such for free software, but for a standalone expensive unit where is the line drawn? Reading pages and pages of these fixes would really make me scared to upgrade. I want to upgrade in a controlled fashion fully understanding what I'm getting myself into when performing the next update.
I support a few open source tools myself and have created some network management tools, some visualization tools, a few opengl games, etc.... I'm a lead developer for a large automaker and I'm basically saying that I'm picky when it comes to these things because I engineer these types of systems.
I'm curious how you are licensing the underlying Windows OS shipped with the standalone units? Do we get license keys, Microsoft updates, etc? What version is this embedded system exactly? If I called Microsoft and showed them your product page, they wouldn't care? Just checking
Is there a reason anywhere that this has to be windows? Windows sucks for car pcs in my opinion and my own embedded Linux development with a vanilla kernel running full blown Slackware is booting in 12 seconds from power being applied (counting POST) . That's X11 running fully and ready to render OpenGL. How fast does this unit boot? Mine was an AMD Geode at 500mhz with 256mb SDRAM running on 12volt. I have a few other embedded machines but I haven't tried optimising those yet. I know the new stuff is faster anyway.
I'm somewhat considering working on gauge software for Linux simply because a windows based embedded device just makes me cringe. That and my coding style simply is less "Cowboyish" and more of a slower and stable approach. After all I have code in production at many automotive facilities running without issue. It seems these updates are really quick to make large changes without much documentation besides "Oh yeah that got disabled" when someone asks. Is there a project roadmap besides the latest "word" on what he's working on? A roadmap beyond the next 4 or 5 releases I'm talking about here.
I'm just curious how this is all working out before I fork over my cash. Do I ever have to "leave" the interface and switch between apps in the base Windows OS? Can I skin the entire interface beyond the gauges? Those default Microsoft styled raised grey buttons over the top of the background simply make me cringe. It's like pre .net VB days and Geocities all over again. All that work to style everything, and you back out a screen only to see those default buttons?!?!
To gain logging performance I'm interested in something running optimised C or similar with tight code and O(n) or at least linearithmic O(n log n) performance. Separate logging thread from drawing thread from control thread. These devices are only getting more CPU in the form of multi-cores. Threading is pretty much a requirement in 2011.
I'm sorry to post something so large, but I simply have lots of questions and want to see how polished this thing is. Videos of it's operation are curiously missing besides a few gauge shots. What about the other functions/screens? Is the gauge needle movement smooth or jerky? How many updates per second are the gauges achieving? I'll admit Hamish seems to be doing a fantastic job. I'm just one of those **** types who will reinvent the wheel because I can just to have complete control over it. That's why I mostly use free/open source software. Give me the code *I fix my own bugs*. It's a shame it's closed since I'd love to hack on a project like Evoscan.
Why should I buy this over DashDaq? Why shouldn't I install a touchscreen in the dash and simply use a tucked away netbook running $25 evoscan? So many questions......
First it appears this is largely a beta app since people are constantly having minor "onesy-twosy" type issues. Am I correct here? I understand some people tolerate crashes and such for free software, but for a standalone expensive unit where is the line drawn? Reading pages and pages of these fixes would really make me scared to upgrade. I want to upgrade in a controlled fashion fully understanding what I'm getting myself into when performing the next update.
I support a few open source tools myself and have created some network management tools, some visualization tools, a few opengl games, etc.... I'm a lead developer for a large automaker and I'm basically saying that I'm picky when it comes to these things because I engineer these types of systems.
I'm curious how you are licensing the underlying Windows OS shipped with the standalone units? Do we get license keys, Microsoft updates, etc? What version is this embedded system exactly? If I called Microsoft and showed them your product page, they wouldn't care? Just checking
Is there a reason anywhere that this has to be windows? Windows sucks for car pcs in my opinion and my own embedded Linux development with a vanilla kernel running full blown Slackware is booting in 12 seconds from power being applied (counting POST) . That's X11 running fully and ready to render OpenGL. How fast does this unit boot? Mine was an AMD Geode at 500mhz with 256mb SDRAM running on 12volt. I have a few other embedded machines but I haven't tried optimising those yet. I know the new stuff is faster anyway.
I'm somewhat considering working on gauge software for Linux simply because a windows based embedded device just makes me cringe. That and my coding style simply is less "Cowboyish" and more of a slower and stable approach. After all I have code in production at many automotive facilities running without issue. It seems these updates are really quick to make large changes without much documentation besides "Oh yeah that got disabled" when someone asks. Is there a project roadmap besides the latest "word" on what he's working on? A roadmap beyond the next 4 or 5 releases I'm talking about here.
I'm just curious how this is all working out before I fork over my cash. Do I ever have to "leave" the interface and switch between apps in the base Windows OS? Can I skin the entire interface beyond the gauges? Those default Microsoft styled raised grey buttons over the top of the background simply make me cringe. It's like pre .net VB days and Geocities all over again. All that work to style everything, and you back out a screen only to see those default buttons?!?!
To gain logging performance I'm interested in something running optimised C or similar with tight code and O(n) or at least linearithmic O(n log n) performance. Separate logging thread from drawing thread from control thread. These devices are only getting more CPU in the form of multi-cores. Threading is pretty much a requirement in 2011.
I'm sorry to post something so large, but I simply have lots of questions and want to see how polished this thing is. Videos of it's operation are curiously missing besides a few gauge shots. What about the other functions/screens? Is the gauge needle movement smooth or jerky? How many updates per second are the gauges achieving? I'll admit Hamish seems to be doing a fantastic job. I'm just one of those **** types who will reinvent the wheel because I can just to have complete control over it. That's why I mostly use free/open source software. Give me the code *I fix my own bugs*. It's a shame it's closed since I'd love to hack on a project like Evoscan.
Why should I buy this over DashDaq? Why shouldn't I install a touchscreen in the dash and simply use a tucked away netbook running $25 evoscan? So many questions......