Slashdot Mirror

Right-to-Repair Law To Get DRM Out of Your Car

Right to repair proposal

Congressmen want automakers to cough up diagnostic codes

The EFF's Fred von Lohman, however, pointed out that there's a certain irony in this widespread public support and Congressional interest. What the bill suggests is that the sort of market created by the DMCA, in which companies are given the right to encrypt and protect information of their choosing, shouldn't apply when it comes to autos. To be clear, there are implementation differences. The DMCA could still apply in that third-party tools that provide access to encrypted data in a car would still run afoul of the law. But the need for these tools would be severely reduced by the fact that the manufacturers would be required to provide an equivalent. That would also, presumably, eliminate most of the incentive for manufacturers to take action against the providers of third-party tools.

From Car Makers Put FPGAs In The Driving Seat

ProASIC3 devices are also designed with an on-chip 1024-bit non-volatile flash ROM (FROM) and a built-in 128-bit AES decryption core, which facilitates independent, secure, in-system programming (ISP) of both the FPGA core array fabric and the FROM itself. This allows designers to implement a number of secure features. For instance, an AES master key can be preloaded into the device in a secure programming environment. Users can then ship 'blank' parts to an insecure programming or manufacturing centre for final personalisation with an AES encrypted bit stream.

Actel Drives FPGAs 'Under the Hood' Into Critical Automotive Powertrain and Safety Systems

    Actel also announced today that Delphi Corp., a leading global supplier
of mobile electronics and transportation systems, will be using the Actel
ProASIC3 FPGA in a production engine control module being designed into a
heavy-duty diesel engine. Additionally, Magna Electronics has selected the
Actel ProASIC3 FPGA for its automotive vision systems (see release "Magna
Electronics Chooses Actel's ProASIC3 FPGAs to Enable Automotive Vision
Systems" also announced today).

Magna Electronics expansion in Rochester Hills to focus on developing electric car program for Ford

Magna Electronics discussed plans for what it calls its intelligent power systems group during a news conference at the Rochester Hills City Hall. The expanded unit, which is expected to add 90 employees over five years, will develop hybrid and electric drivetrain systems and electronics that control motors.
The parent company, which is working with Ford Motor Co. to develop a battery-electric small car by 2011, ...

Magna Powertrain and Hyundai announce joint venture

Charles Kittel, Herbert Kromer, Thermal Physics
Consise, a small set of problems, at least look at every one

Hans Ohanian, Gravitation and Spacetime
Could prevent you from boggling at Misner, Thorne and Wheeler

Stephane Mallat, A Wavelet Tour of Signal Processing
Thorough, a math processor here told us that the demand for rigor could invariably be handled by saying "Lebesgue limit theorem."

Cornelius Lanczos, The Variational Principles of Mechanics (a paperback from Dover books)
Classic introduction to the calculus of variations and analytic mechanics

Paul Horowitz, Winfield Hill, The Art of Electronics
The first edition, before they threw in all the microprocessor stuff, is focused on what experimental physicists need to know.

One of the grand old men of analog chip design, Bob Pease, has written a column for years that you can read on the web.
http://www.elecdesign.com/Departments/DepartmentID/6/6.html
http://www.national.com/rap/

Most cellphones coming out now (with the notable exception of smartphones (except for Blackberry)) are Java enabled. If you've purchased a game on your cellphone is it likely written in Java.
Motorola was among the first to adopt Java in all their new phones: http://www.wirelessdevnet.com/columns/oct2000/mobd ev13.html

Since then most other cellphone manufacturers have jumped on the bandwagon: http://news.com.com/2100-1001-268154.html, http://archive.chipcenter.com/knowledge_centers/wi reless/news/showArticle.jhtml?articleID=10800173

As for hardware execution of bytecode, what's happening now is not the original approach that Sun attempted (i.e. integrating a bytecode interpreter right into the CPU). What is happening now is that several vendors are selling "accelerator" chips that sit between the CPU and the SRAM and execute the bytecodes for the CPU. This modular design has made it easier to integrate these accelerators into existing designs. The Nazomi JA108 is one of the more successful models from what I can gather.

You still have to run a virtual machine, however with the accelerator chip actually executing the bytecodes you get vastly improved performance and reduced battery drain.

Some of these accelerators are even finding their way into other technologies as well, not just cell phones: http://www.elecdesign.com/Articles/Index.cfm?AD=1& ArticleID=1916

I could polish up this list a little but Google is your friend too :)

This article in Electronic Design Magazine is on electric and hybrid vehicles in general, and prominently features lots of details on the Tesla Roadster.

It's also got a ~300 mile range on a full charge, and has a top speed of ~130 MPH, which it can do in reverse.

And its starting list price is $92K, not $98K...

The article also states that they are working on a four-door sedan that they expect to release in 2010 for "about half the price of the roadster."

The Roadster happens to be their first production vehicle. I'd expect it to be expensive. They have a lot of custom parts in that car, and they have to recoup all of the costs associated with custom tooling. If they design future models to reuse those parts (which they'd be stupid not to) that's a significant savings. Which is evidenced by the announcement that the sedan will be half the cost.

Fundamentally, capacitors store electricity (electrical charge), batteries do not - they convert electrical energy into chemical energy in a reversible manner. The charge/discharge curves are very different, most batteries will provide a pretty steady voltage until the chemical energy is almost depleted - capacitors will exhibit a smooth drop in voltage as the electrical energy is removed. Batteries won't work in normal resonating circuits because they don't have exponential charge/discharge curves like capacitors. This is also the main reason that capacitors won't replace batteries for simple circuits - a battery can be equipped with a simple buck regulator and provide very acceptable service. Because of the exponential discharge curve of a capacitor, making effective use of its stored energy requires a much more complex (and costly) regulator.

While one can encounter "leaky" capacitors, that is not a necessary characteristic, and some commonly available ones do very, very well

Capacitors are not exclusively used for their ability to release energy quickly - high capacity ("gold" or "supercaps") ones are often used as backup power sources for low current applications (such as real time clock keepalive), due to the fact that they can be expected to have longer lifetimes than batteries.

Actually they're dead easy to make. Get a digital potentiometer (variable resistor) and connect it as a current source. Hook your LED up to the current source and there you have it. If you want schematics, try this article.

declining job market like computer engineering

Sorry, are you on crack?

However, the best opportunities await those who studied engineering, computer programming . . .

AeA Announces Job Growth Despite Decline In U.S. Competitiveness

Better hunting, bigger salaries greet graduates

You might want to do a quick Google News search before posting a bunch of unsupportable crap next time . . . just a thought.

Please, why are you linking to kooks like Infowar? Here is the original article, which they conveniently don't link to. Compare and contrast. Infowar:

Imagine a place where if you say something considered by the authorities to be suspicious a team of agents is dispatched to your location to detain and question you.

Of course, the lip reading technology isn't even in existence yet, let alone any kind of government plan to use it or secret police squad. From the original article:

Richard Harvey, a senior lecturer in computer vision at the University of East Anglia in Norwich, England, is embarking on a three-year project that will collect lip-reading data.

It's just hype to promote a new research project. Infowar seeks out anything that can possibly be used for bad purposes, and spins it out of all recognition. It's a site run by a paranoid kook, not a legitimate news source.

Linux takes way too much space for an embedded OS and REQUIRES a 32-bit cpu.

If you're not using all the features of the kernel you can strip it down (2.6 is even more modular than previous) and get it under a megabyte. You can use fbui and for another ~50kB get a gui with a window mangler in the kernel. uClinux runs on more limited systems (including those without MMUs). It runs on several 16 bit platforms, for example H8 300S.

It's also quite complex and therefore better suited to larger and more featureful devices. Even there, the numerous distributions lack of standards and standardized packaging and nonstandard GUI hampers it.

There is no support for your argument that it is better suited to larger and more featureful devices, because again, you can strip portions out of it.

Since these aren't desktop devices, your complaints about desktop linux are utterly irrelevant.

That's the reason why PalmOS, Symbian, QNX and wxworks exist. Not to mention eCos, uOS, FreeRTOS etc. Linux is not simply the best tool for the job. Linux is the best tool for certain jobs, the rest will require you to choose. The mobile market is just too diverse to standardize.

All of those exist because Linux was not ready to do those jobs (or didn't exist) when they were created. Many of them have no reason to exist now, except that they are better-supported than Linux (a correctable problem) or that they are FAR smaller, in which case they are not really suitable for a mobile phone either because you will have to develop too much of the software. Which is why we use operating systems and don't just write one big program.

Here's a fail-safe igniter schematic you can use.

http://www.elecdesign.com/Articles/Index.cfm?Artic leID=9252

Most of the postings so far have it all wrong. Google is not proposing 12VDC into a desktop PC or 12VDC distribution within the data center. What they're proposing is that the only DC voltage distributed around a computer case should be 12VDC. Any other voltages needed would be converted on the board that needed it.

This is called "point of load conversion", and involves small switching regulators near each load. Here's a tutorial on point of load power conversion.

It's been a long time since CPUs ran directly from the +5 supply. There's already point of load conversion on the motherboard near the CPU. Google just wants to make that work off the +12 supply, and get rid of the current +5/-5/+12/-12 output set.

Speaking of complexity causing headaches for users, consider BMW's iDrive interface. Almost everybody who's ever used this human-machine interface has concluded that it is needlessly complex and difficult to use. BMW - The Ultimate Driving Machine...for driving you crazy perhaps.

If I was riging it up, I'd use something like RS485 into sealed units with a small custom board in a sealed unit with the sensors hanging off of that. Then you only need one or two PC's outside plugged into the networks of sensors to read off the data and log it.

You could plug pretty much any PC with a serial port in, with a converter like:
http://www.advantech.com/products/Model_Detail.asp ?model_id=1-1TWNLI

The only dificulty left is working out what kind of connectors you can use, if it's all hard wired, then it might be fine to wire the cables though sealed gromits into the boxes for termination.

The protocol could be quite trivial too, say send a couple of characters like R521,53 to say you want to read sensor 53 on unit 521, it'd run out over the bus, get picked up by the right unit, and reply a short time later with something shocking like V521,53,258 (where 258 is -15 degrees in kelvin).

But don't take my word for it, just build a low temprature version of:
http://www.elecdesign.com/Articles/Index.cfm?AD=1& ArticleID=6191

Not the first asynchronous microprocessor either.

This little beauty is over a year old:
http://europe.elecdesign.com/Files/33/9980/Figure_ 01.jpg

And even that wasn't the first, I'm sure.

(I seem to remember aynchronous ARMs back in the last millennium (ARM3 days, I guess) but can't be 100% sure)

Here's a holographic projector as well, albeit, 2D.

http://www.elecdesign.com/Articles/Index.cfm?AD=1& ArticleID=5820

Embedding the firmware makes it impossible to inject your own firmware and makes it MUCH MUCH harder to tell how the chip works. So, yes, Microsoft could stop people from reflashing their DVD drives.

Unlike the CPU, the chip that drives the DVD rom can be completely re-implemented with a relatively cheap FPGA. You can reverse engineer chips with electron microscopes, although it is really expensive. Mod chips could still be produced even if Microsoft decided to start making their DVD-ROMs with an embedded firmware.

I doubt embedding the firmware into the DVD controller is really an option for Microsoft since that would drive the cost of the DVD-ROM way up. Microsoft currently just reflashes standard Samsung and Hitachi Serial ATA parts with their proprietary firmware.

Unless Microsoft radically changes the way they make the 360, this attack should work.

This kind of technology, using an animal to control a vehicle by converting the animal's responses into control inputs for the vehicle, goes back at least to WWII... you can see a picture of one of Skinner's pigeon-guided bombs here and here, and more details here.

It was never deployed, but it worked more than half the time in test runs... how good are today's "precision" munitions?

It's probably the JTAG debug logic. Most modern CPUs use a JTAG port (full-duplex, multi-device serial port) to provide access to internal CPU state, as well as providing hooks for starting and stopping the processor.

JTAG is a hardware test standard, but chip vendors define their own extensions to it to provide software debug hooks. Most PowerPC chips use what's called the Common On-Chip Processor (COP), which is controlled through the JTAG port. The specific details of COP and its implementation on each chip is proprietary, and usually only available to IBM, Freescale, and a few select tool vendors with NDAs. Here's a link to some more information on PowerPC COP:

http://www.elecdesign.com/Articles/ArticleID/3675/ 3675.html

http://www.hybridsynergydrive.com/

Even http://www.elecdesign.com/Articles/ArticleID/11347 /11347.html says it's a hybrid serial or parallel drive.

The simulator shows you when it can run as a serial-hybrid. Try to understand it.

Yes, the comments are actually more useful than the article. I was actually trying to link the comments.

Read this on other damage caused by ozone emitting "air cleaners"

http://www.elecdesign.com/Articles/ArticleID/11084 /11084.html

By Bob Pease, a living national treasure amongst hardware engineers. He does yearly walks in Tibet and discusses how he keeps his batteries charged: http://www.elecdesign.com/Articles/ArticleID/4251/ 4251.html

More than you might think. I've seen an increasing number of devices that come with switching power supplies, either internally or as a replacement for "wall wart" power supplies. Improvements in ICs for switching power supplies have made them cost-competitive or cost-superior to many traditional power supplies. See here for an example.

You're still talking about a 68000, a chip introduced in 1979 and whose lineup maxes out at 16 mhz with no likelyhood of ever going higher. A low-powered arm would be a far more modern and powerful choice. In addition, a GB of ram these days costs 100 dollars. 256 MB of Compact Flash costs 20 bucks.

The HP calculators are generally more powerful, though they have stagnated too, but they're bloody impossible to use. HP's odd notation is not something to be taken lightly.

TI has long included 3D as a function in its calculators, so obviously there is some demand there. When working with 3 Dimensional graphing in college, I had to pull out my laptop and use Apple's built-in graphing calculator because my 200 dollar TI-92+ would choke on it. TI also includes the useful ability to graph multiple functions on top of eachother, but provides no clear way to tell them apart. Again, color would be useful here.

My old Clie which I use constantly can go for months between charges, has 16 MB of ram, a 16 MHz 68000, a greyscale display, and I bought it for 50 dollars. And it's positively antiquated compared to the Full-color clie I bought my girlfriend with a 400 MHz Arm and 32 MB ram with a Compact Flash card slot for LESS than the cost of the v200.

My point is not that the calculators are useless, my point is that they are taking a years-old design that rightfully should cost about 20 bucks and making a fortune on markup. They're doing the bare minimum required to stay in the game, when they could be doing far, far better for their customers.

The calculator racket is due for a shakeup, and soon. Nobody can rest on their haunches to the degree that TI has and expect to stay on top... If for no other reason than technology has passed them by.

The article is kinda skimpy on details for those of us who are visual-type people, so here is a link to an image comparing a PCMCIA card to the two ExpressCard forms.

Enjoy!

FLOOBYDUST? Been reading Bob Pease? I just found his stuff recently.

It's comparatively easy to make a low gain stage with decent linearity from either tubes or transistors. It's not so easy to make a stable tube amp with 120db open loop gain as it is a transistor amp, which means a very good tube amp might have an order of magnitude more THD (ie .02% at 1khz vs .002%) - meaningless unless you spend your time listening for sine harmonics. However, where it counts, it's relatively easy to make a tube amp with 20db or so open loop gain that, with just a tiny bit of feedback (maybe even just a db or two) will be very stable and have very good power response... and low THD (as if that was what mattered).

The seventies and eighties saw a home hifi market flooded with crap gear from japan (Manufacturers like Sansui and Sony and Kenwood and Pioneer) that boasted incredibly low THD... and provided its owners incredibly bad sound.

ZIP drives, well, not cheap and not small, and not widely built-in by box builders and (some think) not all that reliable.

CD-RW, well, not small, and the software was not built-in until Windows XP, and even that software is "one big burn" and doesn't let you copy/delete individual files one at a time so you can use it "like a floppy" and (some think) not all that reliable.

Then we come to USB disk-on-key. Small, software already mostly built-in, random access, can be used "like a floppy". Not real fast, but probably works pretty good for many floppy-like applications. But will it work for data backup? Most people aren't aware that the technology there tolerates a quite limited number of rewrites. Will people be happy when they discover their $50 USB dongle fails after less than a year of daily backups?

When it comes to making casual backups, the battle to replace the floppy is still ongoing. Maybe there'll never be a clear winner, or maybe it's going to be one of these technologies.

Ok, here we go!

x86 Linux, x86 Solaris, x86 BSD, Sparc Solaris, MacOS, x86 Windows, Symbian OS (mobile phones), Palm Pilots (Superwaba runs on mine!)... J2ME also runs on smartcards, pagers, set-top boxes.

Also, please note this CPU that executes Java bytecode as it's instruction language.

To pick a nit...

It's BMW that has the much-maligned iDrive interface with the puck-shaped controller on the center arm rest. this article says that it's starting to suck less, but I'm not sure I'll believe that. I know for certain I'll never buy a car with a Microsoft-designed user interface.

You're telling me a DSP can't handle signals between 20 - 20kHz correctly, when the things are used in the Ghz range? And you want me to take you seriously?

Incorrect. There are a number of single-chip GPS solutions (here, (here, and article here), that are being integrated into GSM phones. There have been substantial problems reaching the FCC E911 requirements using only EOTD (Enhanced Observed Time Difference). And then there's the problem of those areas serviced by only a single cell, where the best location estimate only narrows the position down to an arc up to several miles long with radius x in one sector of the cell. Like long stretches of rural interstates, for example.

That's not to say that GPS-based solutions aren't without their problems. Picking up a GPS signal indoors in a steel-framed building is a substantial challenge, even with assisted GPS (where the cell system itself provides additional timing information to improved signal acquisition).

This reminds me of Field Programmable Gate Arrays. Can someone explain the difference?

WUSB wouldn't really be suitable for a camera.

• 54Mbits is Damn fast, you could send that whole 1gig CF card in 2.52Min. Most Hard-Drives max out at around 200Mbits, and I doubt if many CF drives can read at more than 80Mbits. By the time WUSB is out I imagine a 200+Mbit/s 802.11 standard will be around
• the article says it uses 300mW, that's considerably more than current low power 802.11g chips at 200mW. Bluetooth chips can have sub 20mW consumption.

Many flywheel systems use smaller flywheels spinning much faster. Take this one, for example, at 60,000RPMS and 23Kg.

Still, if you can't afford lead acid batteries, you probably can't afford flywheels for the scale of the system.

The FCC's talking about powerline broadband. Yeah, we're nowhere close to a commercial rollout yet, but at least the regulators are certifying that the plans won't cause massive harm to any other communications tech, so they're about to sign off on it.

Have we just completely forgotten the problem of BPL totally killing HAM radio?

Just some background information for you to read.

If Taguchi works as well on spam we can just about forget another spam control methods!

everyone here is making stupid jokes because they don't understand what the product is. i was skeptical at first, but i looked around at some of the documents on the site and did some googling and found this is actually kind of interesting.

here is a relevant article that explains the technology a little better.

It's unbelievable that someone who knows something of embedded systems would post this kind of vitriol without posting benchmarks or, at the very least, performing a google search first. It's also disturbing that the myth about Java's slowness is still stuck in people's heads. Java's bytecode certainly does not execute as fast as native code, but making a blanket statement about the poor performance of every JRE and Java program is absurd. See this 2 year old article: Embedded Java

Embedded Java is a very big thing; please see:

Javas Consumer and Embedded Technologies
Key Embedded Java Standards
EMBEDDED SYSTEMS GO REAL TIME WITH JAVA TECHNOLOGY
Using Java Technology to Standardize Real-Time Development

Learn C. It's pretty similar to Java...

Well, sort of. Java does share some of its syntax with C, so it will look familiar to a C programmer, but this is an oversimplification. Java has no preprocessor, global variables, pointers, goto statement, struct type, union type, enumerated types, bitfields, typedef, function pointers, or variable-length argument lists. Java has well-defined primitive type sizes, where in C it is dependent on the platform. Java has objects and method overloading, where C does not. Java has garbage collection, where in C you have to roll your own. In Java you can declare variables anywhere, but in C you cannot. Finally, Java has no need of forward references. Your toolchain is also completely different - not just your compiler, everything. In addition, the programming methodologies you use with Java are entirely different from those you use in C. If you want to move from C to Java and still program effectively, you have to learn a completely different way of thinking.

Remember that you are going to be controlling things, not drawing widgets on a screen, so an OO language is not really necessary (or even desirable).

I'm curious, why do you say that OO isn't desirable? I can see that it may not be desirable on a system that has existing APIs written in C, but for new systems, why is this a poor choice? From personal experience, I have encountered a system whose flagrant abuse of structs and function pointers was enough to make a sane man weep. OOP would have really helped to make this more understandable and compact. I've also heard some arguments that object-orientated (Java, C++) and procedural languages (C) are both poor choices for embedded systems, and the best paradigm to use is a logic or declarative programming language.

Instead, you will be reading and writing IO ports, which will involve a certain amount of bare metal programming. Java won't really let you do this.

Again, sort of. Usually, any system that supports Java is going to provide Java layer drivers for its hardware, just like any system that supports C is going to have C APIs. There are some good processors specifically designed to run Java programs in an embedded environment that provide Java access to the HW layer. In addition, any J2ME system has standardized ways of accessing the hardware that most J2ME users will use. Please see the following:

Dallas Semiconductor TINI
Imsys SNAP
J2ME

If there is still some piece of hardware that you don't have a Java API for, you c

Or a capacitor or battery recovering after a heavy load has been disconnected. This phenomenon is fairly well known to people doing electronic design, it may not be so well-known to the public at large, and there is definitely a big "gee-whiz" effect to it.

One good reference I know of is this article by Robert A. Pease.