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


It is currently Tue Mar 19, 2024 6:00 am




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

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
:( OH, THE HUMANITY :(

I've decided its time to stop throwing random bits of Python at the screen to see what works and write the beginnings of a protocol spec based on what I've done so far....

You in t'office with a bit of spare time tomorrow Chris?


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 6:42 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
Off to my favorite site tomorrow :(

Will be in on Saturday all being well, but don't expect much inteligence :lol:

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

Image


Top
 Profile  
 
PostPosted: Thu Feb 14, 2013 7:55 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
oh ffs
After all that, I google CAN temp sensor on the offchance and find there's a whole standard :(

If you've got SAE access (I haven't) have a look at J1939 standard

http://zone.ni.com/devzone/cda/epd/p/id/6215


Top
 Profile  
 
PostPosted: Sat Feb 16, 2013 10:12 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
Circuit design done apart from connector (which I need to choose finally)

Struggling to find a connector rated to 20A, but I've stumbled on this which looks interesting. It may also save searching for a box. The only downside is the connector pins are only tin plate not gold so I wouldn't want to see these outside the cabin unless they're in a larger sealed box.

http://docs-europe.electrocomponents.co ... d4e8d6.pdf

Anyway, progress so far for anyone interested.

https://dl.dropbox.com/u/8316230/PDU/PDU_A.pdf

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

Image


Top
 Profile  
 
PostPosted: Sat Feb 16, 2013 10:30 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
just dropping part numbers for future reference

RS.
664-7236
664-7226
664-7267
664-7258

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

Image


Top
 Profile  
 
PostPosted: Sun Feb 17, 2013 10:26 am 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
Been having a rethink. Just goes to show what happens when you let boffins loose on a design and forget about the application, we've ended up with a spec similar to the motec we were slating earlier.

the whole concept of canbus / remote switching is lots of small cheap simple modules placed next to the item they're controlling, thus minimizing. Wiring.

the other IMPORTANT consideration is making something quick and easy to diagnose and repair by the roadside with no tools or specialist knowledge.

So let's say a module goes pop that drives fuel pump, or headlights when It's dark.. easiest to carry a spare module, but then you need a laptop and adapter and knowledge. So, carry a full set of spare modules ready programmed ? Seems ott.

I think we need to look at the config for the whole system as a single item, downloadable via the canbus and stored in full in every module. Each module will access only the parts it needs based on its address. This means modules can be swapped for each other or a single spare without a laptop. The only proviso is that the address must be settable by the roadside, either a dipswitch inside or imo in the loom with links on 4 inputs (allows 16 addresses)

So. Ditch second chip and dual canbus (since they're not such a problem) go back to 8 in 8 out plus 4 in for address setting.

maybe in the future do a high reliability motorsport version with dual can and other similar redundant device / auto switchover features.

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

Image


Top
 Profile  
 
PostPosted: Sun Feb 17, 2013 1:01 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Hmm
I think the design you have is OK with twin processors
The way I see it the electronics is cheap compared to boxes, connectors etc and the board cost won't differ much. The more cheap io you can pack into the expensive box the better imo - hence it strikes me as a better option to go with the board design you had which is double handy for development

The config thing I had an idea about. After yesterdays elm327 discussions how about making a phone/tablet the central monitor?
I don't think it's unreasonable to expect that the sort of nerdy person who would deploy a can power distribution grid will have a smartphone :lol:
If all else fails and you really need the on the fly capability you can buy a cheap tablet and elm device for under a hundred sheets - pretty reasonable and the kids get a new toy when daddy isn't out terrorising the streets

Failing that making the network self heal is still only a software problem. For eg
Every module on the system backs up the config of the unit before it - 2 has the config for 1, 3 has it for 2 and 1 has it for 3. Say you pull unit 2 and replace with an unassigned one. Unit 3 needs to see unit 2 isn't talking any more and send out the commands to reprogram a blank unit


Top
 Profile  
 
PostPosted: Sun Feb 17, 2013 4:20 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
A few reasons for the decision.

1. Split processor software nightmares.
a. Thinking through how the software will work, each chip sees most of the other stuff via it's own canbus (if it works) but can't see it's other half except via I2C. If one canbus fails, we need to pass everything via I2C. The only way I can see it wotking as original concept is to pass ALL canbus traffic via I2C to other processor, in both directions. So, 2x canbus at 250Kbit trying to pass through 1xI2C at 100Kbit. Sausage up an alley but in reverse.
b. Setting config & upgrading software. 1xUSB port to PC, 2 chips. Who has control ? Or configure / upgrading via Canbus - has to be done twice, once for each chip.

2. The board is now bigger / more complex than the ECU. Adding the connector exceeeds the pin limit on my version of the CAD system and will require upgrade to the full unlimited version. At the time I bought it, I was evaluating several and it was cheaper to buy the demo & upgrade to full than to buy the full. I always intended to upgrade when needed, but I haven't needed to in 10 years and TBH I think the market is so limited it doesn't justify the money. So - cut it down or shelve it.

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

Image


Top
 Profile  
 
PostPosted: Sun Feb 17, 2013 4:53 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Ah, I was thinking along different lines, initially at least

Both connected to the same bus with switchover so basically 1 pdm would appear as two entities on the bus. So everything is identical between software.
Additional development could then allow the i2c bus to come into play to combine the 2 units into 1 via internal comms

The pin limit is a bit of a domestic pachyderm though :(
Is that down to laying the pdm and dash display on a single board?


Top
 Profile  
 
PostPosted: Sun Feb 17, 2013 8:58 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
All being done on different boards, the manufacturer is combining them for me.

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

Image


Top
 Profile  
 
PostPosted: Mon Feb 18, 2013 1:12 pm 
Offline
Group B
User avatar

Joined: Sat Sep 02, 2006 3:13 pm
Posts: 3679
Location: Bournemouth
Car Model: None
Part numbers for smaller, cheaper version of box & connectors.

664-7220
664-7204
664-7254
664-7267

Thinking of laying out board so all the important connections are on the 30 pin connector so some applications can save a connector.

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

Image


Top
 Profile  
 
PostPosted: Tue Feb 19, 2013 12:00 am 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Been exercising the old grey matter to produce a cycle accurate version
I now have real (virtual) hardware to play with so now have correct timing

@250Kb/S CAN speed
16 inputs. Each pin sent with full 16 bit accuracy
each packet takes ~500uS
16x = ~8mS as per picture (packets vary a little bit in size due to bitstuffing required in the protocol)
It's a bit tight :(

Image


Top
 Profile  
 
PostPosted: Tue Feb 19, 2013 11:44 am 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Bit of datapath parammeterisation later

Now running a max of 8 inputs all with 12 bit resolution. Each PDM now takes ~1.8mS to transmit a complete input compliment
I've cut it down so each PDM has a 5mS window allotted and defined a max of 7 PDMs (+ an additional central control unit) on the network. Image shows 7 pdms all talking. Bus utilization is ~35-40%
In this configuration response time is 40mS max - almost quick enough to ditch change notification and just rely on periodic status updates

Image


Top
 Profile  
 
PostPosted: Wed Feb 20, 2013 2:49 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
Random thought of the day

And if the boards aren't done and dusted......

If using a single dsPIC you have a free SPI port. SPI powered SDCARD reader modules are cheap enough....
How about storing the configuration on a SDCARD? That way if a PDM fails on the road you can swap it for a blank one simply by swapping SDCARDS
This has a couple of benefits -
Reduces NV memory requirement
You can configure the system offline then just plug the cards into modules
It gives you somewhere to log stuff like faults
Frees up 4 more inputs to the outside world

Downsides
You need a card reader + slot in the case somewhere
PIC code needs to be able to support SD - a brief search suggests that RAW format isn't difficult

Not sure of the size limit but I'd estimate a complete system configuration to be >1KB :-
@8 pdm with 8 inputs you have 64 input pins in the system
each output needs a "turn on" and a "turn off" flag for every input pin - 128 bits
each output needs some config data - flash, flash rate, current limit. Say 32 bits
There's 64 output pins in a 8PDM 8 output setup so total is 64*160 bits or ~1300bytes

Allow for a few missed things and I reckon 1.5kB of NV memory should be close


Top
 Profile  
 
PostPosted: Wed Feb 20, 2013 3:00 pm 
Offline
Club Staff
User avatar

Joined: Thu Jul 14, 2005 12:44 pm
Posts: 4067
Location: drinking devil fuel
Car Model: ST205
On a related note

Image

Anyone got an ASIC going spare?? :lol:


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 7 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