dimented24x7

iTrader: (2)

Found out something neat. With the AVT-852 acting as a comm port, tunerpro can, with effort, send and recieve OBD-II scantool data. I only requested three items so far, and its just from a test bench PCM (so nothing but default values), but it works, and works without dumping any packets, at least on the bench. In the car, it will likely dump packets occasionally as the PCM may or may not process the lower priority requests of a scan tool, but the intermittent "0" here and there doesn't seem to be a big deal on the scan tools. For retrofit OBD-II setups with only a PCM on the OBD network, it should process 100% of all the requests. For actual OBD-II vehicles, my experience is that you end up dumping stuff due to the traffic on the network. Nice thing is that the AVT handles all that automatically, so as far as tunerpro is concerned, its no different than a standard ALDL cable, just a lot faster.

RBob

iTrader: (1)

Cool stuff indeed!

RBob.

EagleMark

Very exciting!

I have an AVT-853 and a 98 Vortec truck if you need vehicle testing. For awhile anyway, I've got a Moates RoadRunner on the bench waiting for it.

Is there a supplier of the AVT-853 cable yet?

UNEEK

Not quite the first OBDII logs with TunerPro and an AVT, here is one that can log a fair few items ... http://delcohacking.net/forums/viewt...hp?f=10&t=2314

Also for those with an ELM .. http://delcohacking.net/forums/viewt...hp?f=10&t=1320

dimented24x7

iTrader: (2)

Right after I posted someone sent me the one for the LS1 from Jayme. It does, however, not work in vehicle, only on the bench when the PCM is still in the boot sector of the ROM. It attempts to run in 4x mode, and get EVERYTHING (J1979 + GM specific PIDs) at 80 Hz. The PCM will reject any 4x response when the engine is running due to the high overhead of processing data from the datalink controller (DLC). It may run at 1x, but at a very slow rate.

One thing to keep in mind is that there are typically a lot of other nodes on an OBD-II network, so there is limited bandwidth for scan tool data. Im shooting to have maybe 20-25 items at 4 Hz, which should be reasonable rate that wont cause the PCM to dump a lot of the responses. If you send too much and flood the FIFO buffer of the DLC, it flushes everything and all your requests are lost. The MCU can only process so much at once.

dimented24x7

iTrader: (2)

For those who want a unit, contact AVT and send a request for quote. They sell in individual quantities of the cables and interfaces. You send payment on a purchase order and they ship the unit to your door.

I paid about $240 for the AVT interface and OBD extension cable.

JP86SS

iTrader: (1)

I've been toying with the ELM327 and have had some success, Higher item counts seem to shift or misplace responses (I think)
i'm sure at $240 a pop the AVT is a better interface but I'd like to continue trying with the ELM.
Even with some commercial scan tools the ELM seems slow.
Do you feel the ELM is too slow of an interface to pull allot of data items or is more of a matter of priority and sorting out the responses properly?
Jp

Link to the discussion on TunerPro site and gearhead.
http://www.gearhead-efi.com/Fuel-Inj...-OBDII-plug-in

dimented24x7

iTrader: (2)

The elm should work the same as the AVT interface in 1x mode, theoretically. The 1x limits the amount of stuff that can be sent over the OBD port. It only runs at 10.4 kbps. I set up the ADX to have 12 PIDs, and at most it can do 3 frames per second running flat out on an LS1 PCM. The AVT does 230.4 kbps over the USB, so its probably spending most of its time on a digital smoke break waiting for the PCM to process the requests. Some of the problems with dumping frames may be due to not waiting long enough for a reply, or the PCM dumping the request due to high overhead. The commercial scan tools seem to dump data, too. The frames from the scan tool have a low priority, and the PCM services most of the other nodes ahead of the scan tool. You can set them to have a high priority so they dont get dumped, but I wouldn't recommend it. In a later model car, you could get things like periodically dead gauges in the dash due to lack of data refreshes from the PCM.

dimented24x7

iTrader: (2)

In regards to the actual data transfer rate and timing, from what I see, the average OBD-II message frame is about 7 bytes long, and it takes two frames to request and recieve one PID, so thats roughly 112 bits. The PCM seems to take 1/40 th of a second to process a complete PID at 10.4 kbps, so the time needed to transmit a frame is about 6 msecs, 12 msecs for the PCM to process the frame, and then another 6 msecs to transmit a response, on average.

This is, of course, with the PCM on the bench and no other nodes on the network. I suspect that in a late model car, it probably would take 2x longer to pull a complete frame.

UNEEK

The delcohacking ADX works in aussie LS1 commodores, 4x works with the engine running. Its not just a bench ADX.

The main difference with these and what your logging is that there are two data bus, ALDL and OBDII. The translation of the different format is handled by the PIM (powertrain interface module). The majority of devices on the bus (dash, BCM, ABS, climate control, radio etc) are all on the ALDL side with frames translated so the PCM gets to know what is going on. The AVT is connected to the OBDII bus (both bus appear on the vehicle data connector).

dimented24x7

iTrader: (2)

Oh. OK I see. Its for AU vehicles. From what I've seen in my US 98 PCM, 4x is barred when the engine is running. I seem to recall that with the LS1 PCM as well, but its probably worth checking. Caveat emptor then is that not all US vehicles will work with that ADX.

dimented24x7

iTrader: (2)

Heres the software logic from my 98 PCM:
Engine off, vehicle stopped, and security granted. I'll have to trace the '01 LS1 PCM software and see if that one allows it.

Jayme304

Hi mate, im terms of how my adx actually works, it does have a lot of pids defined, and I add more as I need them, but it doesnt actually pull every pid, you may notice there are a bunch of macros, and I only pull a few at a time. mainly I use a macro that combines one pass of a 'low priority' pid with one full cycle of all of the 'high priority' pid's, so I end up with rpm, map, o2 mv, etc in high resolution where I need them, and the other low priority things like coolant temp it only grabs one from the low priority list per cycle. the 80 hz isnt 80 cycles, rather 80 pid's processed per second, so its not as quick as it sounds, and that only works at that speed on my core I7 desktop on the bench pcm, in a real car its between 35 and 45 hz.

its quite easy to remove the 4x initialisation from the initial connect sequence as ive labeled it all pretty well if you want to give it a proper go on your car. as said before, I made it for aussie commodores as thats the only ls1 vehicle I ever tune and ive used it on dozens of them from VT through to VZ.

dimented24x7

iTrader: (2)

Jayme. As the holden's PCM allows 4x than more PIDs are possible. Im aware that the "Hz" is the time to transmit/recieve one frame of data, which in our case is one PID. With those of us stuck in 1x, the standard OBD scan tool data set can only be refreshed at about 3 to 4 times a second.

Im not poo-pooing your ADX. Its very nice and complete. But in this discussion it seems that there are some definite differences between the PCMs used there and here, which should be taken into account. Its easy to change, never the less as its just a matter of tweaking what is requested thru the OBD port.

dimented24x7

iTrader: (2)

Jayme, nother question, while your here

I notice that after sending AVT specific commands, you have the command to recieve the two byte response from the AVT with no processing. Any particular reason you did that? Just wondering if theres something Im missing. In theory, tunerpro should just bit-bucket everything in the COM port buffer that isn't used.

Jayme304

Mainly to keep those replys out of the way. from what ive seen, the avt saves everything in memory and sends the whole buffer when you request data. im just doing that to read those 2 byte replies out of the way so it doesnt interfere with the next frame I want to read. given all of my reads are aligned to the header anyway so it cant read the wrong byte, but I just felt that handling the correct responses at the correct time was a neater way of doing it, and easier for others to read later and see every byte that gets passed back and forth and what its for.

dimented24x7

iTrader: (2)

Also, where did you find all your GM specific PIDs? I got a bunch from reversing the Vortec and LS1 PCM software logic, and put the interesting ones in an excel sheet ages ago. There are some that aren't in your ADX such as the status bytes typical of the older ALDL data stream, injector BPW for each bank, etc. Im regretting not finding them all, as I will likely never be able remember enough to trace it.

dimented24x7

iTrader: (2)

When I open it in a terminal application, it just dumps everything back through the COM port that it sees on the OBD bus. At least thats what it appears to do. Do you recall where that was in the manual that you saw that? Be nice to know for sure if one has to worry about overruning any internal buffers in it.

Jayme304

got a bunch of the pids from here http://www.fastfieros.com/tech/vpw_c...n_protocol.htm
there is an old excel sheet ive got somewhere else with a bunch of them too.

maybe im overdoing it with mine and the reading bytes are completely pointless but with a lot of the stuff ive logged with the serial port logger it looked to me that you actually specify the number of bytes to read form the serial port in the code. so read one byte, which is the number of bytes to follow byte, then read that number of bytes, then keep reading till U get a > 0 packet which is the start of the next packet (this is how a listen to chatter app worked that I was playing with). I just had the idea in my head from playing that the avt is buffering it, I cant remember if it was int he docos. its also possible that im completely wrong too :P


anyway I have so far had 0 feedback at all for my adx lol I had no idea anyone was looking at it or using it till I saw your thread. just happy that its at least being looked at or learnt from by people, thats why I put it up there

dimented24x7

iTrader: (2)

Heres the first version that does the basic SAE scan tool data. Works in my car with the engine off, but I have a u-drive setup, and the alternator voltage is too low when the engine is running at idle, so I can't verify how well it works. Only data logs for a few seconds before it shuts off. Without 12 volts, it only recieves messages, and gives an error when I try to transmit on the bench. Same thing it does in the car, so I assume it needs more juice to work.

Hopefully a new pulley solves the problem...

Edit: See post below for correct ADX. Zip below does not work.

EagleMark

Was going to give that a try... Nothing in that Zip folder? Tried changing extension to adx but TunerPro did not like it? Also I have an AVT 852 which I think is what everyone would want, much cheaper with USB port unlike AVT 853 with ethernet port?

JP86SS

iTrader: (1)

Thanks for sharing guys.
Jayme, I found your adx and am I'm looking at the responses.
I'm struggling with my ADx and am wondering about the responses being different than the send string and the "align with header' check box.
Since yours is in hex it will take me a bit of time to change it to ascii and figure out what its all doing, can you shed some light on it if the resonse strings are related to the comm device or is actually part of the PCM response.

I'm uncertain if the Plugin and the ELM will do 4 digit PID requests and I will try some to find out. Thought i found something that would prevent it but forget where.

Dimented24x7, zip file is blank (or it needs to downloaded with Firefox)
Jp

dimented24x7

iTrader: (2)

Try this one and see if it works. Not sure why it was empty.

dimented24x7

iTrader: (2)

Whats showing there is the actual SAE or GM request for the PID as an actual OBD-II message. The format with the AVT is the first byte is the size of the message to be sent (the AVT uses this to ID what it is to send). The next bytes in hex are the standard OBD message format over the GM VPW port. This is the actual data that will be sent. The AVT works directly in hex, and has a controller that handles the rest.

The AVT then relays ALL the messages it recieves from the OBD port through the COM port. Tunerpro then looks for the response. The PCM will always follow the standard by sending the typical header with the PCM as the source, and you (the scan tool at either 0xF0, or 0xF1) as the target in a physical message, or in the case of a functional message, just the scan tool address). Basically to get TP to respond, you type the first bytes of the message that the PCM will send, which will always follow the SAE standard. Since they follow the standard, you know that after the initial message, the PCM attaches the PID data you requested. Selecting "align to header" lets TP know that it should immediately grab the specified packet of bytes right after the header, which will be 1, 2, or 3 bytes. These bytes are your scan tool data (cool temp, RPMs, etc.)

dimented24x7

iTrader: (2)

Im still having issues getting the AVT to work with the engine running. Im guessing there is noise in my electrical system that is causing the AVT to not properly send data over the OBD port. Im guessing that the unit stops sending data as it detects it as a power fault. The AVT will recieve data, but responds with an error message when I try to transmit.

The AVT has rather basic power and signal conditioning hardware. 12V in is just a voltage regulator with the standard pre and post capacitors. Signal conditioning is an RFI choke and a bypass cap on the OBD data line. Im thinking thats not enough to clean things up. I'll have to see what AVT has to say, but I suspect that it will need an RF choke for both power and ground to isolate it, and then an RC filter and TVSS to provide clean power to the unit. Im surprised they wouldn't put that stuff in to begin with.

EagleMark

Works great for me!

Stock 1998 5.7L Vortec Silverado.

Started engine and had AVT-852 cable hooked up, clicked connect in TunerPro RT and viola! Data!

Here's a data log file.

EDIT: The adx says 853 and the thread is 853, but your picture of board says 852 like mine...

Double EDIT: I added a bunch of dashboards and monitors to your ADX to help the effort!

dimented24x7

iTrader: (2)

Your right

The 853 is the ethernet version, the 852 is the USB version. Got my numbers mixed up.

dimented24x7

iTrader: (2)

Thanks for the additional updates. I also plan on one with extended GM data logging similar to what Jayme has, but in a more compact form for the slower 1x data rate. As you can tell, it goes at 1/4 the speed (20 Hz) of what the aussie cars do.

Also, did it experience any errors while logging? A couple is to be expected as I have it set to wait a max of 1/10 of a second for a reply. If the PCM takes longer, then that PID is skipped.

EagleMark

Nope, smooth as silk. I attached a short data log so you could see. It was a cold start, never warmed up.

Connected and disconnected a few times, restarted truck and conected again. Could not make it fail.

I watched the Hz and was looking for any glitch. One thing I did notice and should show in the log, when I revved engine the HZ went up.

If you want more log or? Let me know.

EDIT: I did find a couple files you may find handy but I think they are CAN...

dimented24x7

iTrader: (2)

No it sounds like its working for you. I think my issues are mainly with noise. I have lo-z ignition wires and a high-output coil on my vortec ignition. Even with the distributer phased to give the smallest spark gap in operation, it still generates a fair amount of noise on the AM channels. It could also be something like a bum diode in the alternator. Im going to do some tests to isolate whats bothering the AVT. It sounds like the guy that designs these is willing to make some changes based on what I find. Right now, there is very little in the line of noise isolation in the AVT.

EagleMark

We just fixed a simalar issue with OBDI and data. Changed the wires. He just happened to notice the noise in radio, noise was gone after SP wires were changed.

HTH!

dimented24x7

iTrader: (2)

I also found out that for the AVT-852, the baud rate in TP has no effect on the unit as its going thru the USB. I think the baud rate is dependant on the speed of the USB, and thats it. The drivers for the vcom port handle the rest.

dimented24x7

iTrader: (2)

I suspect that its noise on the +12V from the alternator. Im going to patch in a power supply in place of the +12V of the OBD port. If it works, then its junk on the +12 volts. If a choke is needed on the - as well, then its common mode noise. If it STILL doesnt help, then its the worst case, which is noise on the OBD bus, which is harder to get rid of.

I dont think its the USB, as the unit works fine in the car when its hooked to its own supply and a test bench PCM.

EagleMark

Lots of bad stuff (RFI/EMI) happens with Solid Core or Low Resistence Spark Plugs wires... not so bad on old cars as it just messes up the radio. But on EFI cars all sorts of bad things happen.

HTH!

dimented24x7

iTrader: (2)

I know, but right now they're the only aftermarket show in town. As far as I can tell, MSD has discontinued the standard carbon polymer core ones for the vortecs in favor of the "super conductor" wires. Even the terminals they make are now just for the super conductor wires. The SC wires aren't true solid copper core wires. They have a lo-z carbon core with coiling around it to attempt to suppress the extra EMI. Sort of a compromise between solid copper and carbon polymer. Theyre about 50 ohms/foot. I still have the standard AC Delco resistor plugs, and I wonder if that does more harm than good. They create a large impedance mismatch, which could generate standing waves on the wires.

Whats interesting is that the PCM isnt botherd by it. My flash chip is mounted externally on the PCM in a ZIF so I can get to it. So far, no issues.

rocko350

Hook up multimeter on the output stud of the alternaotr while the vehicle is running. if your getting more than .30 volts AC the diodes are done and are leaking. Run new twisted pair wires to the ecm communications wires to help make sure they have good isolation. Make sure they are the same length. this is an issue on trucks i work on when someone "repairs" a communication network wire. Creates all sorts of issues on the CAN network.

Try to make sure the stainless braided ground strap is on the engine down to the frame, and the frame is grounded to the battery. Body should have a copper strap to block and a copper wire to battery. This helps to "scrub" the higher frequency electronic noise back to the block. A poorly grounded motor or body will allow the cooling system to become a battery component due to the coolant passing along disimilar metals in a magnetic environment.

Chris

dimented24x7

iTrader: (2)

I tried the AVT on its own +12V power. Works fine sharing a common ground with the vehicle, so its not any issues with the OBD bus, which isnt surprising. Since the OBD bus is a current based system that uses pull up resistors, its fairly immune to noise. The noise is on the +12V either from the alternator, ignition, or something else. The grounding is good. All the leads are clean, and the ground straps for the body are all in place.

The alternator is a powermaster unit, and I've always been a little suspitious of it. The field windings will howl sometimes rather than the usual wistle that GM alternators make. I did check it with a DVM some time ago, and the ripple seemed reasonable. Hard to tell without an oscilloscope, though. I used to have an old heathkit geriatric case, but the sweep tubes in it finally puked and it just had a stationary dot on the screen.

At any rate, the AVT should have more than just a voltage regulator. Be real easy to fry the thing if you forget its hooked up and crank the motor over.

dimented24x7

iTrader: (2)

Ok so I broke down and bought a portable scope meter. There is a lot of noise coming from the ignition, but doesnt look like its from the actual spark: https://www.thirdgen.org/forums/tech...-ignition.html

I was playing around with it and I still can't really figure out why the module generates a sharp pulse when it shuts down. Basically on the trace the voltage sags down when the ignition module turns on, and then when it switches off, there is a sharp 10-15 V spike. Could the inductance of the alternator or the wiring itself cause that? Since the module isnt ballasted like the older HEI ones, Id suspect that it pulls around 20 amps when it switches on.

dimented24x7

iTrader: (2)

I got this fixed a little while ago by building an inline LC pi filter into a small box with DB-15 connectors. Finally got some time to do actual datalogging with it. Really good tool to log with now that it works the way it should. Cant believe how flexible tunerpro is, too! I finally got around to calibrating my VE tables. Really neat to use the MAF, RPM, baro, and IAT to simply spit out a VE table with no effort at all. Engine runs MUCH better on tip in now that it has the correct VE tables to use during load transients. Only downside is that with 1x VPW, I have to be selective with what I can request if I want data fast. On the upside, adding whatever you need to the ADX def isn't too hard. Just have to write macros to request the data.

EagleMark

Pretty cool to see TunerPro History tables used in new ways! I'm always looking for new things for them to do.

Look for a GM PID name GM.DYNAIRTMP_DMA instead of IAT. I beleive this is what the PCM uses not IAT alone. The PCM calculates the charge temperature (in degrees Kelvin) using the following formula 273.15+IAT+((ECT-IAT)

Is the VE table in TunerPro XDF set for percent or GM Grams*Kelvin/kPa ? The number you came up with in histry table don't seem to match either? Are they corrections?

For percent:
{SAE.MAF.gps}*{CALC.DAT.K}/{SAE.MAP.kPa}/{SAE.RPM}*3445.2/displacement()"
"{GM.DYNAIRTMP_DMA.C}+273.15" is Calc.dat.k

For Grams*Kelvin/kPa:
"{SAE.MAF.gps}*{CALC.DAT.K}/{SAE.MAP.kPa}/{SAE.RPM}*15"

Those will do a calculated VE in closed loop. Or if TP is capable to swtich from LTFT to WB by using GM Eq ratio for a switch, 1.00 would be closed loop and over 1.0 is adding fuel so calculattions would need to be set for WB using lambda. EQ ratio is like Lambda in reverse.

Some of the calculated VE can be further filtered from inaccurate data by removing TPS% movements in a spreadsheet.

EDIT: Nevermind, I don't think the 98 vortec can do that. I thought you were working with the LS 0411 XDF you have. I recently changed to a 0411 PCM and run a 12212156 OS. The 12212156 OS is much better then older LS 0411 OS and can be flashed into older 0411 PCMs

EagleMark

I think what I did with the Vortec PCM was make one based off the 0411 LS OS with a look up off Blend factor and Blend filter to come up with GM.DYNAIRTMP_DMA Because GM.DYNAIRTMP_DMA would not show as a supported PID out of the Vortec PCM.

Also it changes weight from ECT to IAT with incresed airflow.
"lookup({SAE.MAF.gps}, 0,0.60010, 10,0.17139, 20,0.12842, 30,0.08594, 40,0.08106, 50,0.07129, 60,0.06201, 70,0.05469, 80,0.04736, 90,0.04297)"
"{SAE.IAT.C}+({SAE.ECT.C}-{SAE.IAT.C})*{Lookup}" Then you have the Calc.Dat for above.

dimented24x7

iTrader: (2)

I haven't switched over yet because I like the code a lot better in the vortec PCM. I customized it to basically be a blend of the stock code and code from my TBI MAF project. The LS1 PCM is nice, but the model based logic and cylinder airmass for everything are not as intuitive as the standard MAF logic with MAP based SA tables. Also, I haven't had a chance to work with the later "unified" OS that your running. Theyre all the same base kernal, but a good bit different than the '0` I started working with. Also probably better than what I started with in the '01 LS1 PCM as you say.

As for the SD calcs, the vortec PCM just uses the IAT IIRC as it had a plastic intake manifold, so the engine cool temp did not impact it as much. The LS1s also had the plastic manifolds, but the option to blend the IAT/CTS as you said in the code. I have a victor e intake which is an airgap style and a CAI, so I left the logic as it was with just the IAT.

As for the VE table values, they are straight VE for the engine. The engine has a large cam, high flow heads, 80 mm MAF, 1000 CFM TB, etc, so it moves a lot of air, around 320-330 grams at WOT, which is cross-checked with the WB-O2 just to make sure the data is accurate. Since its set up mainly for WOT performance, the VE is kinda crappy at low RPMs and loads. The VE tables in the Vortec/LS1 PCMs are normalized for engine displacement, so in my XDF I set the conversion to automatically adjust them back to actual VE using the cylinder displacement so they dont display as funky units like HP-Tuners does.

dimented24x7

iTrader: (2)

Im going to refine the routine a bit to use more general density lookups on IAT, actual GM mass airflow which is more accurate, and hopefully automatic baro calcs so the VE calculations can be more accurate. As for filtering out throttle movement, not sure that could be done with tunerpro. I just inspect them and toss out the ones that only have a few samples, or are in error, like those values at high RPMs/low loads, which are during throttle transitions. I may also expand the VE so the 5200 RPM cell doesn't also contain data all the way up to 6000 RPM, which is why its lower than its neighbor. Never the less, its a very nice way to tune.

Saar

this has been confusing me for quite some time....

so the VE tables aren't actually VE tables(in that they're simply a multiplier), but actually combine a few calculations and make what are essentially "cylinder airmass vs RPM vs MAP" or "cylinder airflow vs RPM vs MAP" type of tables?

EagleMark

I've been playing with your XDF and the older 2001 LS OS with the RoadRunner and it's a great way to use the 0411 PCM.


IMO continuing work should be in the 12212156 OS, it would be a one cure all to even include the Vortec to 0411 swap using a 2002 Express van bin. That one OS is better, but the range of vehicles it covers is the real key. We have been collecting .bin files for this OS as well.

Also on the MATemps, implementing them in a $0D MPFI swap has shown some great adjustments in fueling with the same Victor intake your using with MAT in an existing hole... number 8 intake IIRC. Idle MAT was around same as ECT, but at 2000 RPM there was a 40+f drop which made BLM/INT do zig zags, they stabilized quite nicely with addition of MAT in that mask do to BPW adjustment vs temps. This was without MAF...

EagleMark

From GM they are Grams*Kelvin/kPa and in EFI Live they can be displayed as what we are used to VE % as well. Not sure what HP tuners does...

dimented24x7

iTrader: (2)

From my memory, theyre a combination of VE and engine cylinder displacement. Thats what I could tell from back working the fuel calculations in the PCMs. Everything but the cylinder displacement was accounted for in the SD airmass calculations.

Saar

there's always a first time for hearing a term, but what advantage could there possibly be from going to that different of a method for calculating airmass?

so a single table takes account of VE, airmass temp and density... ?

dimented24x7

iTrader: (2)

I'd have to go back and check the LS1 code and GMs source code to be sure of the actual units for the LS1, but I seem to recall that being L/kPa or L * kelvin / kPA. This is why the nested cylinder displacement is implied, so they work out to be liters directly. Grams directly would not make sense as the air density is highly non-linear, and must be done as a lookup prior to calculating the air mass. I think the vortec and the LS1 where the same in that regard, but it would be nice to know for sure.

EagleMark

That was exactly what I looked like the first time I saw it!

1.1xxx

When set to VE% it looks normal. 50

When set to grams/cylinder it looks like dimented24x7 history table above. .0xxx

When set to grams/second it is 123.xxx and looks to be same as TunerCat...