www.gt4dc.co.uk
Maintain, Modify and DRIVE your GT-Four


It is currently Tue Mar 19, 2024 12:44 pm




Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Tue Feb 12, 2013 2:41 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
I'm stuck at home with an severe outbreak of my comedy midwinter hayfever so have thought about stuff a bit more

TL;DR version
Image

AWOOOGA, AWOOOGA, NERD ALERT, NERD ALERT, AWOOOGA AWOOOGA
Technical version


Bit of back of smog packet claculation since my model is :-
a) Not cycle accurate (or even cycle aware :lol: )
b) In the deleted items folder due to a rethink

Give each PDM 16 inputs max with 12 bit analog resolution based on PIC capabilities, Max 256 on a single network (4K total inputs :shock: )

For every input each pdm needs to send a status packet roughly like
Code:
|  address    |    Data (16 bit)     |
{xxx,(pdm num)}{function(4),Value(12)}

Major Priority Groups denoted using upper 3 bits to achieve quickest conflict resolution (Assume 0 = highest pri, 1=lower)
Code:
   Error            :- {000}XX
   Highest (config)   :- {001}xx
   State Change       :- {010}xx
   State             :- {100}xx


In round terms each packet is 7 bytes:-
3 data/address,4 protocol
So each PDM sends 16*7 bytes = 112 bytes
112bytes = 896bit/pdm
Say bus is 250kb/sec
each pdm uses ~3.6mS
Call it 5mS to allow for a couple of higher priority state change messages

You end up in a 256 PDM system with a native refresh rate of 1300mS but cut it down to a more likely 64 pdm limit (or possibly a more useful 32 pdm but 32 inputs) and you get < 500mS native refresh.

I've left out the possibility of all PDMs reporting back their status as it just doubles the refresh time anyway :lol: and there's no allowance for state change on outputs - the protocol is more than robust enough for the benign vehicle application with a 15 bit CRC and the slave can report any errors on output switching/normal refresh


Top
 Profile  
 
PostPosted: Tue Feb 12, 2013 4:54 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
I doubt most systems would have more than half a dozen units.

For polling, I would send data on ALL inputs in eack packet, so the overhead will be much smaller. i.e. 16 x 2 bytes = 32 bytes data + 5 overhead = 37 bytes per PDM.

For an absolute worst case (IMO) of 16 units that's 592 bytes.

At 100Kbaud (I think that's standard rate from memory) that gives 60mS assuming 10 bits / byte.

I need to start thinking about how to implement the logic. My first thought was to have a master controller + slave I/O modules, but I'm starting to think in terms of putting the logic inside the I/O modules on a 'per output' basis. i.e. for each output you can specify a logic equation of maybe up to 8 inputs plus timers to define whether it should be on or off.

I've still got plenty of time to think about the software side of things, the main thing I want to get done quickly is the hardware design so I don't need to pay another 'minimum charge' for a batch of prototypes.

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Tue Feb 12, 2013 5:25 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Trouble with that is ye cannae do it cap'n

Max data payload is 8 bytes. I doubt you can even get the vanity light in the sunvisor to get out of bed for 8 bytes these days :roll:
Plus there's a big penalty if the message does get corrupted

My first model built the smarts into the masters
So if pdm 2 detects indicator switch -> turn left it sets the relevant outputs in pdms 1 and 5
This is traffic inefficient and has issues when say both door and boot are open and one is closed. It's tricky not to turn off the courtesy light with the door still open. Certainly doable but it gets ugly

Currently working on a system where slave outputs are "subscribed" to master input change notification which should work better

Hardware wise as long as it sits on the can bus and can send or receive messages that,s fine. All it then needs is some of those switch/sense modules connected to output ports,inputs to monitor them and a few inputs for switches/volts


Last edited by two_OH_five on Tue Feb 12, 2013 5:52 pm, edited 2 times in total.
payload is 8 bytes you fool and try writing it without risk of offence when none was intended


Top
 Profile  
 
PostPosted: Tue Feb 12, 2013 7:44 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
What's the probability of the system being linked / integrated with another system ? i.e. can I cheat and invent my own protocol ? Is it possible to send more than 8 bytes without other devices throwing a hissy fit ?
I need to check the CAN implementation on the pic as that may limit the number of bytes.

Other possibility is to use RS485 and normal async serial rather than CAN ?

If we're stuck with transmitting 1 input per packet, how about each module has a queue of 'state changed' inputs which get transmitted as priority, resorting to background polling when there are no changes.

Also, how many analogue inputs are we likely to have affecting control ? I'm struggling to think of more than 2 or 3. Digital signals can be transmitted at 1 per bit so we can probably do 16 inputs in a single packet.


So you're looking at putting the logic per input rather than per output ? Bearing in mind many functions involve more than 1 input, I would have though logic per output is more sensible.
e.g.
interior light = left door | right door | boot
Main beam = headlights on & beam.
Dip beam = headlights on & !beam.

I'm trying to think of any devices which wouldn't work in this manner and I can't. We need some sort of master timebase for flashers so they flash in sync, but that's do-able I'm sure.

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Tue Feb 12, 2013 9:00 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
I'd try to stick with vanilla CAN for now. I don't think it's likely to play nice with other systems right from the getgoz as the message IDs will probably clash
In some respects I don't think the actual low level nitty gritty matters at this stage. Protocol can be fine tuned later - it's just software. The thing is that even worst case input per transmission it works well enough. I have some ideas on how to cope with analog/numeric values and how to optimise overall. The way I see it many of these can be very slow update (unless my audio channels work out :lol: )



I think what I'm doing now is per output logic but that's my definition

Basically the inputs(bus masters) are dumb. They just
1) Periodically announce all input states
2) Immediately nnounce a change of input state when appropriate

It's up to outputs to respond to inputs that are pertinent to them



I did initially start out the other way as it has some advantages in integrity - the protocol has a handshake so you have positive message received confirmation immediately from each output that needed switching. So the input knows that all required pdm outputs are on


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 4:48 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
So hows about:

Dual CANBUS with redundancy / fault checking.
Relay contacts on each canbus to disconnect in the event of an internal fault detected.

12 outputs. 20A capability.
1 analogue input 0-5V (pin for optional pull up to 5)
1 analogue input 0-12V (pin for optional pull up to 12)
12 Digital input with pull-up to 5V
4 Digital input without pull up. (pin for optional pull-up)

Facility in software input processing (pre canbus) for up to 2 'pulse' inputs to measure frequency & transmit as analogue value.

Is it worth adding USB for link to PC for programming ?

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 6:05 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
It will need a PC link of some description for absolute certain. There is shed loads of configuration required and it will all be vehicle specific

How is flexible. Either via one of your USB>spi direct dongles as per the ecu or via a USB->CAN adapter. I made provision in my model protocol for command/control via the bus itself.
Ideally you'd program the first unit with a direct pc connection then program additional units on the bus via that first unit as a bridge I reckon
One tricky part is initial programming since default factory flashed code is going to sit everything on the same bus addresses. I haven't found a way around this but it's overcomable by attaching pdm modules to the bus one at a time

Spec wise the hardware looks generally good to me.
For a prototype/proof of concept I'd allow pull down to zero on all inputs - initial trials are likely to hook into existing 12v circuits like light power I would imagine
Thaa would make it a good plan to provision 12->5 conversion on all the inputs since 99% is still likely to be switched 12v at the moment

As far as dual bus goes I'm not sold but I like the idea so why not :D


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 7:22 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
My reasoning for dual canbus is the reputation of a certain BMW motorbike for rides home on the back of breakdown wagons with canbus failure, and the associated joking on the forum about running out of canbus fluid.

Inputs will be capable of withstanding over 12V as standard anyway.

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 7:58 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
I get the idea. Heck I'm concerned about it as I too own a can powered BMW

I'm just not certain that simple dual inputs solves the problem. Relay isolation is good though. Unless a unit passes a POST it doesn't join the bus

The only thing that two cables with software network select protects against is cable hardware damage and the chances are 1/2 the users would switch from a 4 wire to a 6 wire and run both busses down the same cable. You do get protection from a chafing type issue that takes down one bus but it's not protection from chopped cables

Actually I do have the beginnings of what might be a patentable system in mind that does address the problem. Need to give it some thought ...


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 10:14 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
The dual bus will protect against chafing of cable on a sharp edge (most likely cable failure scenario) and Canbus driver chip failure (most likely device failure scenario if the wire picks up a spike). The relays will protect against single PIC failure (relay for each driven by other pic as a cross check) or power supply failure.

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 10:28 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Drifting rather off topic....
Has anyone actually discovered the failure point in the BMW system or correlated the various symptoms to try and guess the failure

Back on topic

Are you planning to effectively have 2 complete systems in 1 pdm box - I.e 2 dspics and 2 transceivers?
Or are you thinking 2 dspics will be required to get the job done?


Top
 Profile  
 
PostPosted: Wed Feb 13, 2013 11:58 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
Planning 2 dspics in order to get the number of I/O up, and also to allow twin canbus.

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 12:14 am 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
Re. the common failures on the bike, TBH I don't usually look in the tech sections as I don't own own one, I just go by the banter in the off topic. Just done a quick search on there and most of the reported problems are down to hanging accessories (satnavs, heated gloves etc.) from the canbux switched aux sockets and the canbus sensing an overload and shutting them down. I guess you can't really blame the canbus for that.
The common 'breakdown' problems seem to be fuel pump controller failure (canbus controlled, but module failure not bus) and the rest mechanical failures, final drives figuring high in the list.

_________________
If at first you don't suck seed, try drier grain.

Image


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 1:04 am 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Not actual issues with can then - good to know

If you've got two pics and two transceivers here's what I would do
Use dpdt relays. In the off state connect the transceivers internally and do a comms check pip to pic. It's also handy for development as one box can talk to itself via internal can

I've imposed some sensible (I think) limits on my system
15 boxes max on a network, ID 1 - 15
Each box gets a 10ms window based on its ID in which it dumps its input status. This allows for up to 32 analog inputs per box but still gives a pretty good 160mS recovery time is things go awry
ID 0 is the default unconfigured ID. When a fresh box falls off the production line it will be defaulted to that so, providing there's only 1 unprogrammed unit on the bus you can talk to it and configure - only done once as it will store its own I'd in flash once programmed

A little out of scope but just for JP :lol:
If you have a spare backup bus doing nothing it is possible to send audio over CAN. If you could build a box that did a single pwm output @ say100KHz then with a 20A current capacity you've basically got 30 watts of class D power to play with :D
Alternatively, and more useful, if not using the twin bus the second input could perhaps bridge onto another canbus giving you the potential to add ecu signals into the mix - handy for a digi dash


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 1:14 am 
Offline
Club Staff
User avatar

Joined: Wed Jul 13, 2005 12:06 am
Posts: 4743
Location: Perth, Western Australia
Car Model: ST205
Music over CAN? The ECU would be fairly jumping with that :lol:

_________________
Don
GT4DC Chairman
1994 Toyota Celica GT-Four ST205WRC JDM 269bhp @ 0.9bar
1994 Toyota Celica GT-Four Special GT 590bhp @ 1.8bar
1989 Van Diemen RF88/89 Formula Ford 1600
2008 Nissan Patrol GU 3.0L ZD30DDTi 154bhp


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group