Maps aren't going to solve your 'pseudo' problem. The ability for the self driving car to ask questions however, is.
I have had plenty of taxi journeys to obscure places where the cabbie has asked wtf are we going, even in my home town. It's not unusual to ask, and being able to reply will help loads.
Add mapping to that and it should be a bonus on knowing where to go. The article makes it that databases should be queryable for anything, and that's not practically possible. Asking questions back is, and generally gets you places (please excuse the pun). any system that can do this is basically going to earn the $$$$
Not bugs - if their adapters start sending random crap over CANBUS, what can I do?
If their adapter dont work ok J1850-PWM (what fords use for the diagnostic bus) what can I do? people instinctively blame the app, rate it bad or (in the best case where I can reply) send an email.
The hardware they copy is buggy, it's well known (ok you may have to search a bit for 'clone ELM237 buggy J1850' etc, but you'll get there if you dig)
The software has been made to work with the buggy adapters, but there's only so much you can do. If you send '0100' and the adpater goes '0102' to the ECU, wtf can I do?!:)
Heh, that's actually a good one that I had completely missed! I haven't a clue about how much fallout there would be, or if it was spread over a wide enough area (hopefully due to pieces burning up) if the residual would be enough to worry about!
It's not the first time they've had problems with chutes either, however this is the biggest one they've done so far, and things don't always scale up (you need thicker fabric, etc to handle larger stresses)
From the limited video footage, the chute looked to be already torn at deployment, so it may have been doomed to fail well before it opened (though NASA have had tearing problems before, one wonders if they had built anything in to mitigate that known risk into the design)
Unfortunately you can't trust electronics in space (see the other headlining article about cubesats rebooting from stray particles every 6 weeks).
One of those particles hits your flash chip, given the size the dies are now, then it's going to effect a large number of cells potentially and corrupt the filesystem quite badly.
Electronics in space have to be uber radiation resistant, this is why it's still 100MHz (etc) stuff that's being used and not the latest GHz stuff, because, reliability in an adverse environment!:-)
This is all well and good having self driving cars, however, (ok, so this is through reading the unfortunate things that happen to people through stupidity, and malice on reddit, liveleak, etc)....
Hopefully we'll never get to the stage where you just 'pop the infant' into the car and tell it to go to grandmas (assuming grandma is there, and nothing happens along the way). Sad, far fetched, but you can bet that this will happen somewhere and some unfortunate may be hurt as a result in something entirely preventable).
This was a waking dream this morning. Sad thing to wake up to. Hopefully never happen.
I'm sure someone has already mentioned this (and I tried posting on the RPi forum but it's having a 'senior' moment)
This is likely just RF overload.
Stick some foil over the RAM and CPU (and voltage reg) and see if things improve - you mentioned flipping the board over so I would imagine that RF (Radio Frequency) is the culprit (as the xenon flash is basically a wideband (all frequencies) radio transmitter). That close is probably going to couple with some squiggly bit of the silicon and do 'interesting things'
Very interested to see if the foil improves things (alu tape would be a good start)!
'Design' would have curved the screen so it fit more comfortably. In their website you can see in the pictures just how awkwardly it sits on the wrist. A bit of a let-down to be honest.
Similar thing with other clones - the bluetooth mac is the most duplicated. there's a valid-looking one (which has basically been used/everywhere/ for that paticular bluetooth module
The re-pairing issue may be an android/bluetooth as well as a combination with the adapter (or it may have been worked around in later versions of android) I'm not sure. Again, it's another headache that developers have to deal with:-)
It is, and it is evidently not working in this instance, is it as FTDI would have already pursued this (and the costs would likely have been prohibitive for little recompense).
Some people have looked at the driver and it writes the EEPROM for every device (I am told). Clone chips apparently are broken by this. Malicious or not, they shouldn't have been using FTDI's driver (they have had every opportunity to have written their own and even use their own device IDs, or license from FTDI properly)
You mean the USB ID was reset to un-allocated because the non-ftdi chip was using a licensed PID that it had no right to.
The devices were not damaged, they still work - they have no driver. This would be the case even if FTDI didn't change the ID, and simply refused to work. You would be in *exactly* the same situation with a device you could no longer talk to as you have no driver.
Get a driver for the device, and it'll work. Won't be an FTDI driver though.
They didn't break chips though - they simply moved them off their USB id.
All you need to do is get new drivers for the USB ID of 0. then things will work again. The clone chip isn't ever going to work with FTDI's drivers though, so you're going to need the clone chip manufacturer to release drivers for their device (instead of using FTDI's which they had no agreement to use)
Linux sorted this out in a patch pretty quick. their ftdi driver works with those devices now, so all you'd need to do is release and pay for a driver to be sent out over windows update.
The biggest issue with the ELM327 clones is that they're very very flakey - the bain of my life!:)
Some have issues with timing on serial data, resulting in garbled output Some have issues with canbus systems and causing the canbus itself to have internal comms problems (causing your car to complain) Some don't work on all the protocols (a PCB design issue) Some get hot and reset Some have dry joints (ok not a chip issue, but a build quality)
I warn the user (but don't stop them) if they have a clone unit (as it's not too helpful), but my stuff gets a *lot* of flak because the OBD adapter is kaput or doing crappy things (the above).:'-(
They didn't break the chips though - they moved the PID to 0 which stopped it using FTDIs drivers. You'd have the same situation if the driver simply refused to work (and you can't use the old drivers as technically you're breaking the license agreement).
This means that someone needs to write drivers for devices witha PID of 0. Fairly simple. and then pay M$ to distribute them (as FTDI did with/their/ drivers)
Linux has this sorted in a patch, and things work again.
But the chips haven't been broken. They work as they did before, just not with FTDI's drivers as the device ID has been moved.
This would be exactly the same if FTDI simply stopped their drivers working with the devices outright (including their old drivers which those chips are also not licensed to use).
If someone writes a driver for PID 0 for ftdi's protocol, then everything will work again. That's down to the clone chip vendors now.
Linux has this already sorted in a patch (they patched the driver to accept PID 0 as a FTDI clone chip). Again, nothing is broken or damaged, it simply won't work with FTDI's drivers or licensed USB ID.
No, not broken - you see the chip still works, but the drivers don't see it as the PID has changed.
And FTDI have no obligations to make their drivers work with that chip.
Linux has already a patch to update/their opensource/ drivers work with the PID of 0. FTDI has no such obligation or intention of letting their drivers work with those devices however, which in windows may mean you have to hack about to recognise the new PID, or get new drivers.
The device itself and chip are fine. You simply have no drivers that recognise the device ids (unless you use linux with the patch)
Again (as per previous posts):) FTDI didn't break anything - they moved the USB ID off their allocated(and payed for/licensed range) and that was that
The chip still works. However, not with FTDI's drivers. this would be the case if the chip was blocked by their drivers or the device ID was changed.
For example linux has a patch that allows the chips to work as a PID of 0. This is the driver that's been updated to recognise it. FTDI have no such obligation in their drivers
Which is what they've likely now started to do in the next update, however:-)
However, the counterfeit chips *chose* to use FTDI drivers by using FTDI's licenced (and payed for PID/VID). That's not FTDI's problem. And FTDI have moved those chips off their USB id.
The chips and device still work, just not with FTDI's drivers. Nothing was 'broken'.
* It is an offence for a person to use an instrument which is, and which he knows or believes to be, false, with the intention of inducing somebody to accept it as genuine, and by reason of so accepting it to do or not to do some act to his own or any other person’s prejudice.
So now, all the people with PIDs of 0, and know about this fiasco, are breaking the law by continuing to use their fake device? (IANAL)
Slashdot Mirror
Permanent pressure on the steering wheel then
Maps aren't going to solve your 'pseudo' problem. The ability for the self driving car to ask questions however, is.
I have had plenty of taxi journeys to obscure places where the cabbie has asked wtf are we going, even in my home town. It's not unusual to ask, and being able to reply will help loads.
Add mapping to that and it should be a bonus on knowing where to go. The article makes it that databases should be queryable for anything, and that's not practically possible. Asking questions back is, and generally gets you places (please excuse the pun). any system that can do this is basically going to earn the $$$$
Not bugs - if their adapters start sending random crap over CANBUS, what can I do?
If their adapter dont work ok J1850-PWM (what fords use for the diagnostic bus) what can I do? people instinctively blame the app, rate it bad or (in the best case where I can reply) send an email.
The hardware they copy is buggy, it's well known (ok you may have to search a bit for 'clone ELM237 buggy J1850' etc, but you'll get there if you dig)
The software has been made to work with the buggy adapters, but there's only so much you can do. If you send '0100' and the adpater goes '0102' to the ECU, wtf can I do?! :)
Heh, that's actually a good one that I had completely missed! I haven't a clue about how much fallout there would be, or if it was spread over a wide enough area (hopefully due to pieces burning up) if the residual would be enough to worry about!
Many more pieces, with a lot more surface area to:
1) burn up with.
2) decelerate with.
One big problem becomes less significant the smaller it gets.
It's not the first time they've had problems with chutes either, however this is the biggest one they've done so far, and things don't always scale up (you need thicker fabric, etc to handle larger stresses)
From the limited video footage, the chute looked to be already torn at deployment, so it may have been doomed to fail well before it opened (though NASA have had tearing problems before, one wonders if they had built anything in to mitigate that known risk into the design)
(*i am not an expert, just an average thickie)
Unfortunately you can't trust electronics in space (see the other headlining article about cubesats rebooting from stray particles every 6 weeks).
One of those particles hits your flash chip, given the size the dies are now, then it's going to effect a large number of cells potentially and corrupt the filesystem quite badly.
Electronics in space have to be uber radiation resistant, this is why it's still 100MHz (etc) stuff that's being used and not the latest GHz stuff, because, reliability in an adverse environment! :-)
Sigh.
You appear to be both wrong. :wq!
This is all well and good having self driving cars, however, (ok, so this is through reading the unfortunate things that happen to people through stupidity, and malice on reddit, liveleak, etc)....
Hopefully we'll never get to the stage where you just 'pop the infant' into the car and tell it to go to grandmas (assuming grandma is there, and nothing happens along the way). Sad, far fetched, but you can bet that this will happen somewhere and some unfortunate may be hurt as a result in something entirely preventable).
This was a waking dream this morning. Sad thing to wake up to. Hopefully never happen.
I'm sure someone has already mentioned this (and I tried posting on the RPi forum but it's having a 'senior' moment)
This is likely just RF overload.
Stick some foil over the RAM and CPU (and voltage reg) and see if things improve - you mentioned flipping the board over so I would imagine that RF (Radio Frequency) is the culprit (as the xenon flash is basically a wideband (all frequencies) radio transmitter). That close is probably going to couple with some squiggly bit of the silicon and do 'interesting things'
Very interested to see if the foil improves things (alu tape would be a good start)!
Regards
piemmm
'Design' would have curved the screen so it fit more comfortably. In their website you can see in the pictures just how awkwardly it sits on the wrist. A bit of a let-down to be honest.
Similar thing with other clones - the bluetooth mac is the most duplicated. there's a valid-looking one (which has basically been used /everywhere/ for that paticular bluetooth module
The re-pairing issue may be an android/bluetooth as well as a combination with the adapter (or it may have been worked around in later versions of android) I'm not sure. Again, it's another headache that developers have to deal with :-)
That right there, you nailed it.
Open standards.
But the USB PIDs are explicitly licensed, so does that not negate it in this instance?
It is, and it is evidently not working in this instance, is it as FTDI would have already pursued this (and the costs would likely have been prohibitive for little recompense).
Some people have looked at the driver and it writes the EEPROM for every device (I am told). Clone chips apparently are broken by this. Malicious or not, they shouldn't have been using FTDI's driver (they have had every opportunity to have written their own and even use their own device IDs, or license from FTDI properly)
You mean the USB ID was reset to un-allocated because the non-ftdi chip was using a licensed PID that it had no right to.
The devices were not damaged, they still work - they have no driver. This would be the case even if FTDI didn't change the ID, and simply refused to work. You would be in *exactly* the same situation with a device you could no longer talk to as you have no driver.
Get a driver for the device, and it'll work. Won't be an FTDI driver though.
They didn't break chips though - they simply moved them off their USB id.
All you need to do is get new drivers for the USB ID of 0. then things will work again. The clone chip isn't ever going to work with FTDI's drivers though, so you're going to need the clone chip manufacturer to release drivers for their device (instead of using FTDI's which they had no agreement to use)
Linux sorted this out in a patch pretty quick. their ftdi driver works with those devices now, so all you'd need to do is release and pay for a driver to be sent out over windows update.
The biggest issue with the ELM327 clones is that they're very very flakey - the bain of my life! :)
Some have issues with timing on serial data, resulting in garbled output
Some have issues with canbus systems and causing the canbus itself to have internal comms problems (causing your car to complain)
Some don't work on all the protocols (a PCB design issue)
Some get hot and reset
Some have dry joints (ok not a chip issue, but a build quality)
I warn the user (but don't stop them) if they have a clone unit (as it's not too helpful), but my stuff gets a *lot* of flak because the OBD adapter is kaput or doing crappy things (the above). :'-(
They didn't break the chips though - they moved the PID to 0 which stopped it using FTDIs drivers. You'd have the same situation if the driver simply refused to work (and you can't use the old drivers as technically you're breaking the license agreement).
This means that someone needs to write drivers for devices witha PID of 0. Fairly simple. and then pay M$ to distribute them (as FTDI did with /their/ drivers)
Linux has this sorted in a patch, and things work again.
Hi!
But the chips haven't been broken. They work as they did before, just not with FTDI's drivers as the device ID has been moved.
This would be exactly the same if FTDI simply stopped their drivers working with the devices outright (including their old drivers which those chips are also not licensed to use).
If someone writes a driver for PID 0 for ftdi's protocol, then everything will work again. That's down to the clone chip vendors now.
Linux has this already sorted in a patch (they patched the driver to accept PID 0 as a FTDI clone chip). Again, nothing is broken or damaged, it simply won't work with FTDI's drivers or licensed USB ID.
No, not broken - you see the chip still works, but the drivers don't see it as the PID has changed.
And FTDI have no obligations to make their drivers work with that chip.
Linux has already a patch to update /their opensource/ drivers work with the PID of 0. FTDI has no such obligation or intention of letting their drivers work with those devices however, which in windows may mean you have to hack about to recognise the new PID, or get new drivers.
The device itself and chip are fine. You simply have no drivers that recognise the device ids (unless you use linux with the patch)
Again (as per previous posts) :) FTDI didn't break anything - they moved the USB ID off their allocated(and payed for/licensed range) and that was that
The chip still works. However, not with FTDI's drivers. this would be the case if the chip was blocked by their drivers or the device ID was changed.
For example linux has a patch that allows the chips to work as a PID of 0. This is the driver that's been updated to recognise it. FTDI have no such obligation in their drivers
They didn't disable it though, they simply moved the PID off their allocated range.
The chip still works, just not with FTDI's drivers. Nothing was broken.
Which is what they've likely now started to do in the next update, however :-)
However, the counterfeit chips *chose* to use FTDI drivers by using FTDI's licenced (and payed for PID/VID). That's not FTDI's problem. And FTDI have moved those chips off their USB id.
The chips and device still work, just not with FTDI's drivers. Nothing was 'broken'.
And an amusing part from the UK law on counterfeit goods: http://www.legislation.gov.uk/...
* It is an offence for a person to use an instrument which is, and which he knows or believes to be, false, with the intention of inducing somebody to accept it as genuine, and by reason of so accepting it to do or not to do some act to his own or any other person’s prejudice.
So now, all the people with PIDs of 0, and know about this fiasco, are breaking the law by continuing to use their fake device? (IANAL)