The Research and Development Thread!!

[TazzI]

As for pricing and release dates. Unfortunately have nothing at all written down for that! Need a finalized design made so that my manufacture and quote up the costs for creating the custom plugs.

I generally do all prototypes in batches of 10's. Which is actually very small quantity.. which means not much savings in terms of bulk buying. Once Iv got a solid design that the manufacturer is happy to pump out, Ill be able to provide estimates on availability and price!


Next step is to start pumping out these designs in the new 3D printer when it rocks up. So should be able to get some real sneak previews soon.

 

[Dirbatua]

i really want to get a 3d printer one day, cant justify the cost to myself knowing im just going to print out stupid **** cause i get bored easily

 

[TazzI]

i really want to get a 3d printer one day, cant justify the cost to myself knowing im just going to print out stupid **** cause i get bored easily

Yeah, its a bit of an outlay depending on what you get. I got something with a track history.. and all automated so the bill was a bit. Theres some cheapo china ones available but they have to be assembled with all 5000+ parts :hmmm:

Oh dont you worry. Im going to 3D print everything!
I want to make a Mug saying Envyous Customs... just not sure if 100deg water will cause it to kinda sag :rofl2:

The material it uses is meant to be the same stuff as Lego... so hopefully should be fine!

 

[Dirbatua]

apparently most of the plastics are good for 180+ degrees, some are good for up to 230 degrees etc, was reading about one printer that uses something that's good up to 800 degrees,

I'd do such childish things with one haha.

 

[vk4akp]

OK. Thanks for all the good info. I'm pleased to see you are confident that the Bluetooth can do the job.
I have had recent devices (Battery chargers) that still suffer from BT dropout and refuse to reconnect till after several reboots.
The Android tablets used are BT4.0 but *IF* the charger is as advanced I have no idea.

I'll look forward to seeing your new interface on the market. I will stand in line patiently ready with some $$'s waiting.

I know you can't give a firm time frame. But do you envisage weeks, months, or years before a final marketable product?

And again is your guess on pricing <$100, $100-$200, $200-$300 etc?

 

[vk4akp]

Oh. And not sure if discussed. But I would love to see that the USB cable is removable. As in a socket in your device for it. Say similar to a USB printer socket. (Type-B).
Nice and sturdy. There's nothing worse then those tiny little mini/micro plugs getting snagged and breaking.
.-.-.

 

[Bigfella237]

~ For the techies out here, the supported protocols are HSCAN, GMLAN, MSCAN, ALDL, VPW and... VPW x4. ~

Would this cable be able to sniff a CAN Bus other than the above?

I'm currently looking at Holley ECUs, which use their own proprietary CAN protocol, unfortunately they won't release any info so I'm gonna need to do it the hard way! I do have some information, they use 1000kbps baud with 96 bit messages (32 bit header with a 64 bit payload), with two ECU parameters broadcast within each payload. There are 24 unique messages broadcast by default so all 24 cycle through every 10ms, although you can add custom data too.

So I guess I'm asking:

a) can I set the baud rate that high; and
b) is there a way to display the raw data (maybe using Wireshark?) and possibly filter some message IDs

 

[TazzI]

Would this cable be able to sniff a CAN Bus other than the above?

I'm currently looking at Holley ECUs, which use their own proprietary CAN protocol, unfortunately they won't release any info so I'm gonna need to do it the hard way! I do have some information, they use 1000kbps baud with 96 bit messages (32 bit header with a 64 bit payload), with two ECU parameters broadcast within each payload. There are 24 unique messages broadcast by default so all 24 cycle through every 10ms, although you can add custom data too.

So I guess I'm asking:

a) can I set the baud rate that high; and
b) is there a way to display the raw data (maybe using Wireshark?) and possibly filter some message IDs

Ahhhh interesting!. Might have to send you a PM on that.

Soooo. First up. HSCAN is my terminology for standard dual wire CAN on the standardized OBD2 plug pins. HSCAN can be a variety of rates including 250,500,1000 and even 2000kpbs. I have set the cable communication up so that a variety of baud rates can be used, the ones Iv programmed in so far are the ones noted above except for 2000kbps since I dont know of anything that uses that speed. Actual custom baud rates could be introduced but currently not added in (Eg. 350kpbs).

But that sounds normal in terms of the protocol. 32bit header (technically would be 29bit header such as 0x102020A0) and then the pay load would be the following 8 bytes which is the standard maximum amount of bytes that can be sent by 1 message in CAN.
Eg. 0x102020A0 01 02 03 04 05 06 07 08

Up to 8 filters can be set so thats not enough for what you need, but you could make a "range" filter which is called a mask... so you could filter and only display everything between 0x100 and 0x200 ect. Alternatively.. allow all messages through.. and filter in PC software to look for only the ones you need.

Id assume there "proprietary" CAN protocol will simply mean that the information they spit out wont follow conventional/SAE standards.. eg... factory Holden ECU's all output specific messages that indicate current gear, speed, RPM ect. Whereas theirs may be different!

Have you hooked onto the line to view this data before? Or dont have suitable equipment to do so?

 

[Bigfella237]

I won't pollute this thread too much with non-GM info but no, I don't even have a Holley ECU to play with (yet)!

The end goal, as I mentioned earlier in this thread, is to create an LCD-based stand-alone DIC, mainly because I need an odometer (my after-market gauges don't have the option), but after much research I figure it shouldn't be too hard to have some trip computer functions and possibly some additional gauges in there as well?

All this would be Arduino-based as I can virtually plug 'n play the CAN transceiver and LCD controller shields together, then basically just read a sensor value off the CAN Bus, do something with it and display it on the LCD (sounds simple don't it)?

But there are untold hours involved with mapping an unknown CAN protocol before I can even think about doing that!

 

[TazzI]

I won't pollute this thread too much with non-GM info but no, I don't even have a Holley ECU to play with (yet)!

The end goal, as I mentioned earlier in this thread, is to create an LCD-based stand-alone DIC, mainly because I need an odometer (my after-market gauges don't have the option), but after much research I figure it shouldn't be too hard to have some trip computer functions and possibly some additional gauges in there as well?

All this would be Arduino-based as I can virtually plug 'n play the CAN transceiver and LCD controller shields together, then basically just read a sensor value off the CAN Bus, do something with it and display it on the LCD (sounds simple don't it)?

But there are untold hours involved with mapping an unknown CAN protocol before I can even think about doing that!

Ahhhh right!

Now Im with you on the stand alone custom DIC.

Right, first up, thats possible!
Generally speaking, the quick,easy and cheap LCD shields dont like being "updated" quickly and results in an unbearable flickering, also depending how much information you display on the screen will also affect how fast it will let you update (eg.. custom gauge). You would be able to read out ECU data waaaaaaaay faster then you can actually display it. Guess it depends on how fancy you want this? Or if your looking to use a cluster (eg VE, VY ect) and retro fit it to the car to display data, odometer ect.

I can vouch for the untold hours in reverse engineering!