-
Still working on my CAN-to-CAN interface from last week. Wasted a lot of time debugging my use of SPI when it turns out that the issue was unstable power to my CAN controllers. Hardware is fun!
I’ve got the interface talking to the new instrument cluster now but as I mentioned last week I managed to damage my donor hardware (while trying to repair it), so this might be the end of the line for this project as I don’t want to take my dashboard apart without a suitable donor to drop in.
At least I have some fun CAN hardware to use in the future!
-
Looks nice, I joined the waiting list.
In addition to the tutorials, which I think will be a key factor for the success of this type of site, having some kind of premium plan with access to factory manuals would be awesome. I remember in my Audi and VW days, people were always asking on the forums for someone with access to a Bentley manual on CD to post screenshots of something they’re working on. I see the same thing now on the Lotus forums where people need an exploded diagram of something to figure out what part number to order.
-
Thanks man!
My vision is to use crowd sourcing. So if you have a vehicle and want to add ‘oil change’ service Maintenr will give you an option to construct service data based on existing user data (if present).
Obviously that’s a lot of work and requires good amount of traction. At the end of the day I would not want to charge regular user for anything (we both know parts and cars are already expensive as is).
I don’t want to disclose too much but the big picture is to have certified ‘Maintenr’ shops that you can ‘check-in’ your vehicle to and share your maintenance history with them and let them add their own records to your vehicle.
I think that would be awesome.
P.S What Lotus forum do you speak of? I’m always interested in additional feedback!
-
http://lotustalk.com is the main one for Lotus owners in the US. There are a lot of how-tos in various threads on there, but it would be great to have a site like yours be able to consolidate all of that in one place. There are also some Lotus-specific sites like Sands that are go-tos for technical info.
-
-
I signed up too!
It seems like crowdsourcing could be interesting if you’re aiming at DIYers - there’s always more than one way to do something and it often differs from the “factory manual” approach, especially when “special tools” are involved.
One interesting idea also might be to ask how-to providers to annotate their “how-tos” with what special tools were called for and substitutes (if any).
-
Thanks for signing up and offering feedback!
When you create a tutorial you can upload images and provide full (markdown supported) comment for each image, I assume if there is a special tool/replacement it would go in there?
Correct me if I’m not understanding your idea right, thanks!
P.S Sorry was going to reply earlier but got side tracked.
-
-
-
-
Doesn’t really matter if it’s slow if you met your objectives. It looks like you learned something and your tutorials are well done!
Have you considered pursuing a fully-unrolled architecture like in this paper or this code? You end up with a 64-deep combinational logic pipeline and instead of using a shifter you just wire the shifted bits across (since your pipeline is fully unrolled). Obviously computing any individual hash takes 64 + load overhead cycles but since you’re cracking you can pump a plaintext each cycle and get tremendous throughput.
-
I considered fully unrolling the pipeline when I was starting out, but decided against it thinking that I could fit more units on the FPGA by keeping the logic block count low. That’s why I did things like using a single 32-bit adder. But even then, 32 compute units take up >30% of the logic elements on the FPGA and an age to compile.
There are clearly a lot of optimizations I could make, but given that I’m so far behind even a CPU I don’t think its really worth my time. I’ll be exploring real-time processing next, which I think the FPGA will be better suited for.
-
-
Writing the software drivers for my FPGA MD5 cracker. This is part of a series of blog posts I’m doing on using the new Arrow SoCKit, an evaluation board for the Cyclone V FPGA/ARM HPS SoC.
-
-
I’m glad you’ve liked the series. Do you find the material covered generally helpful? Is there anything in particular you’d like to see discussed?
Here are some other resources you might find helpful. For learning Verilog, I recommend the tutorials on ASIC World. That’s what I read to learn Verilog after learning VHDL in school. Also, since the Cyclone IV has no hard processor, you’ll want to use a NIOS II soft processor. That’s what we used in my embedded systems class in school. The materials for the class are freely available online on the professor’s website. There’s a bunch of really helpful stuff there on designing for Altera FPGAs, especially in Labs I and III.
-
I haven’t gone too in-depth on it, mostly due to a lack of time (I’ve got a couple of projects that suck up what little spare time I have where I want to do computer stuff). I’ve got a crash course on Verilog that I’ve been following along with, and makes sense (but again with the time constraint). I’ll add the ASIC World link to my wiki page on the subject, a glance suggests it is a good resource.
-
-
-
-
Awesome!
Have you seen Stanislaw Skowronek’s amusingly named “NSA@Home” from 2007 or so?
Different FPGA target but the lookup ideas and switch architecture might be interesting to you. His source is all up here: http://nsa.unaligned.org/rtl.php
-
-
I need an open Driver’s License database w/ images of licenses from all 50 states (of varying ages, too).
-
-
-
-
This is a new project for me, but I guess we want to scan because: (1) not all states support this, (2) and a few states (the smart ones?) encrypt the data in the barcode.
-
Interesting; I think the linked article is out of date as I know that at least Georgia used to use an “encrypted” barcode format provided by “L-1 Solutions” but as of 2012 moved to the AAMVA-recommended PDF417 approach.
But if you need legacy support, I see where a historic driver’s license archive could be useful.
Often bar bouncers will have a “big book” which they use when attempting to authenticate licenses; have you looked into obtaining one of those for your product? It sounds like “open” is useful but not a necessity.
-
-
-
-
-
-
-
I worked on a startup doing this years ago.
There’s actually a lot of low-hanging fruit in web scraping, with the usual associated legal issues.
One challenge with both scraping and user-inputted product data is normalization. “KLNX 6PK 3CT POUCH” is understandable to both a grocer and a POS operator as a 6 pack of 3-pouch containers of Kleenex but extracting that information into a machine-readable format is somewhat difficult.
Once you start trying to use the manufacturer prefix from the EAN/UPC to assist with manufacturer normalization, there’s another problem: often GS1 prefixes are either made up or transferred-by-acquisition so many times that they have nothing to do with the products bearing their prefix.
Open-source NLP pipeline projects (like Stanford CoreNLP) are valuable in this pursuit; many research NERs are already trained to recognize company names and quantities as entities so there’s a lot to work off of.
I posit that an open “crowdsourced” product database should be heavily user-dependent for normalization and should adhere to a strict schema to start; “scan a GTIN and upload a picture and name” will become almost more frustrating than having no data very quickly.
-
-
We used:
Manufacturer has many manufacturers recursively (really "subsidiaries" I suppose) Manufacturer has many brands Brand has many products Product has many SKUs SKUs have many SKUs (recursive, to represent i.e. "case of bottles" or "pallet of cases of bottles") SKU has an association with a numeric (count) quantity SKU has an association with an absolute (measure) quantity SKUs have many barcodesSo for example (bottom up, for a real product)
79285032899 (UPC) -> 0.5oz, 1ct, generated ID (SKU) -> Nude Lip Gloss (Product) -> Burt’s Bees (Brand) -> Clorox
This product is listed as “BURTS B LIP GLOSS NUDE 0.5OZ” in a SKU table from a retailer I found online, so you can see how the simple “UPC, name” tuple often doesn’t quite cut it as useful information.
For user input I suppose an aggressive auto-complete based system with a lot of required fields could be useful, although there’s a balance between maximizing data ingress / difficulty and data quality.
We provided a facility for users to upload pictures of products we didn’t know about and then we would manually input the information (ourselves, interns, etc.) to ensure the best possible normalization and data quality.
Some databases I’ve seen attach even more metadata to SKU, for example “Form” (in the Burt’s Bees example, that’d be “stick”).
One difficulty with this schema was handling GS1 prefixes to try to automatically infer a manufacturer or brand when we didn’t have the specific product. We first tried associating them with brand - that got messy fast. Then we tried associating them with manufacturer, because that’s how the registration process is supposed to work, but that turned out to be lossy. Prefixes ended up being their own enormous independent hierarchy of prefix-brands and prefix-organizations that would eventually resolve to either a brand -or- manufacturer.
-
-
-
-
At work, pixel-perfecting and skinning up a big iPad app for demos soon. I both love and hate this phase of making consumer-facing apps; it’s tedious, frustrating, time-consuming, and sometimes feels wasteful but it’s also the part of the project that garners a lot of immediate positive feedback from stakeholders.
Outside of work, I’m working on a simple CAN-to-CAN middleman device to interface a post-2008 Lotus Elise instrument cluster with a pre-2008 car. The hardware prototype is a Teensy++ 2.0 attached to two off-the-shelf MCP2515-based SPI CAN modules but I’d like to eventually try to make my own boards with a Cortex M0 and MCP2515s together because I’m not a huge AVR fan (it was just handy). So far the hard part has been getting the hardware wired together and working at all; the connectors for the instrument clusters are “protected” so they’re hard to source and I’ve just been jamming connectors onto the pins. The protocol side is pretty easy as the old protocol is documented and, while the new bus runs at a different speed the new protocol seems to be remarkably similar with just a few extensions. Sadly a bench accident broke my donor instrument cluster so I’ll never actually be able to use it in the car :(
-
Currently playing around with using an FPGA to build an EPROM/EEPROM emulator which can have its virtual “contents” altered in realtime. This consists of a few basic design blocks: UART, a simple command parser, dual-port SRAM, and a basic synthesis-time configurable mapper to support different EEPROM / EPROM setups (output enable / write enable and various kinds of clocking).
This device is useful for tuning older automotive engine management systems as on these older systems the ECU would constantly read the timing and fuel maps out of the ROM. By emulating said ROM, the maps can be adjusted on the fly.
A variety of commercial devices which do the same thing exist, but most are quite expensive for what they are ($200+) and use antiquated physical dual-port SRAM modules.
I had the project working for one specific kind of EPROM using tons of level shifters and a relatively big Xilinx Spartan6 part with C running on MicroBlaze soft IP for the UART and command processor.
This week I’ve decided to try to make the design smaller and very cheap by implementing the UART and command processor in the design and switching to an extremely cheap SiliconBlue/Lattice ICE40 part. I’m also trying to make the pinout and EEPROM setup configurable to support more host ECUs.
My main challenge right now is that these older devices are 5V and any kind of modern programmable logic only supports 3.3V I/O. This wouldn’t be too bad (just use basic off the shelf level shifting), except that I now want the pinout to be configurable to support different ECUs. I’m considering using one of the few remaining 5V compatible CPLDs as a configurable level shifter.
The funniest part of this project so far was needing to buy a PCI Express parallel port card to interface with my integration test bench: a cheap eBay “Willem EEPROM Programmer.”