Related
Hey Guys..
i think this software probably doesn't exist.. but i thought let's give it a try
I recently swapped gyms and in the gym i'm now at, when i'm working out, my pulls and pushes aren't counted.. also the distance i pull/push isnt checked like in my former gym.. so i can't watch my technique..
Then i thought.. maybe there's an app wich uses the g-sensor too register the movement of the device and displays them usefull for working out, when i attach my phone to the weights..
Anyone's come across such software??
Thankyou
Well the accelerometer in the phone can only track acceleration (and direction, due to gravity), not absolute movement or distance. To do that, you need a reference point and potentially other sensors (e.g. the Nintendo Wii's IR bar, and the additional angular rate sensors in the MotionPlus accessory).
If you had a set speed, you could calculate distance based on time (which it'd know by the angle of the phone, assuming you attached it to yourself / the weights in a fixed position), but your speed's probably going to vary enough to make the output useless.
hmm.. too bad..
Thanks for the response!!
Where (/dev/xyz... any other evidence of this).. How do we poll it.. Whats the output (units).. What brand of sensor?
It seems most of you know that this device does have this sensor..
And if you must ask, I'd like to get the reading to fine tune - or better put, double check - the offset value for a 2 bar map sensor.. Barometric pressure on a car (most of the time) determined by the reading of the map sensor just before the engine is started.. which makes sense. So you could check your values by measuring the raw voltage of the map sensor with engine off.. putting it thru your linear + offset equation.. and seeing if it matches up to a localized barometric pressure reading.. weather.com.. not exactly localized.
Good question.
It has one according to the iSuppli teardown. It is a Bosch Sensortec BMP085.
Looks like it will output into hectopascals (millibar) with up to 10cm accuracy.
This may be good for:
Pairing up with GPS to give height calculations
Allowing the Xoom to autoswitch into airplane mode
Pilots as an EFB
Location based services
The first one would be awesome if properly implemented.
Here's some info from Google in regards to the API. This link has anecdotal references to temp calculations, so it could be used for weather prediction although it would need a hygrometer to make it practical IMO
Happy development
"•Allowing the Xoom to autoswitch into airplane mode"? I may be wrong but I believe a airplane cabin is pressurized, Wouldn't this affect the sensor reading?
They are.
Regardless of your altitude, chances are that there will be a differential between the ambient pressure and that inside the cabin while in flight. I have a Casio Pathfinder watch and can see the pressure change by a few hPa's.
You are required to turn off all electronics before takeoff, so the function would only be useful if it did a pressure check differential.
Since commercial airliners are typically pressurized to @6,900 ft while in flight, I would log the pressure before power-off, compare it on startup and kill the radios if the delta is too high.
I would set the function to disable the radios first and ask the user if they want to enable them in a pop-up dialog or something. This would be used if something erroneously triggered the function like rebooting when going up 40 stories in a hi-rise or farting on the device as it boots
Anyhoo, I'm just guessing at potential uses. Who knows, it may have made it in as part of the Google Tablet reference and will never be used. I fly quite a bit, so I would like to see something created.
I also don't know the hardware init sequence during startup. The sensor would need to do the check during startup and before the radios are initialized. Doing it after is pointless.
Just fyi, it also has a temp sensor. Think of that as a motherboard temp sensor, depending on where the chip is located. It really is a nice, accurate sensor. Why oh why must cars use this old age 0-5V junk? Before anything can be done.. we probably gotta see how/if android sees the device.
So I wonder what the difference between the following two kernel config options are:
CONFIG_SENSORS_MOTO_BMP085=y
# CONFIG_BMP085 is not set
Is there really a difference between the two? Also, this may be a Tegra thing, as the G-Tab Kconfig has such an option. Doubt it has one, none of the Nvidia developer boards seem to have one.
Can someone ls -al /sys/devices/platform ?
If there's too much 'stuff'.. try ls -al /sys/devices/platform | busybox grep BMP . If you have busybox, that is. Otherwise im sure you can spot anything with BMP in it. Either that or it could simply be called bark sensor. I'd do it myself but I don't have access to the Xoom at the moment.
Oh and don't invoke ls using busybox... its broken.. as is find.
EDIT: NEVERMIND THIS POST!!!!! YAY!!!
So who's as pumped as I am?!!!
cat <kernel-source-root-dir>/Documentation/ABI/testing/sysfs-i2c-bmp085
What: /sys/bus/i2c/devices/<busnum>-<devaddr>/pressure0_input
Date: June 2010
Contact: Christoph Mair <[email protected]>
Description: Start a pressure measurement and read the result. Values
represent the ambient air pressure in pascal (0.01 millibar).
Reading: returns the current air pressure.
What: /sys/bus/i2c/devices/<busnum>-<devaddr>/temp0_input
Date: June 2010
Contact: Christoph Mair <[email protected]>
Description: Measure the ambient temperature. The returned value represents
the ambient temperature in units of 0.1 degree celsius.
Reading: returns the current temperature.
What: /sys/bus/i2c/devices/<busnum>-<devaddr>/oversampling
Date: June 2010
Contact: Christoph Mair <[email protected]>
Description: Tell the bmp085 to use more samples to calculate a pressure
value. When writing to this file the chip will use 2^x samples
to calculate the next pressure value with x being the value
written. Using this feature will decrease RMS noise and
increase the measurement time.
Reading: returns the current oversampling setting.
Writing: sets a new oversampling setting.
Accepted values: 0..3.
I am slightly confused by the last two posts, but yeah the sensortec is a barometer that can compute temperture. Did you check the links above?
Hi folks,
On a lark I tried replacing the digitizer/touchscreen on a freebie Eris donated by a friend.
The old touchpanel was a Synaptics, and was dead/wonky in the lower left hand corner above the home/menu keys (those soft keys worked, however). It had a scratch on the glass in this same area, which led me to think that the repair would be straightforward.
The result was not acceptable, however - it is very "jittery". (The GB Dev Tools "Pointer Location" activity always seems to show a larger uncertainty circle on this unit compared to a different Eris w/ a Synaptics digitizer)
The replacement unit that I received was a Melfas assembly - the 1.49.2000 (S-OFF) bootloader reports it as a
TOUCH PANEL-MELFAS_45_17
Relevant kernel boot log messages (dmesg output post-replacement):
Code:
<3>[ 9.397033] i2c_smbus_read_byte_data failed
<4>[ 9.397125] synaptics-rmi-ts: probe of 0-0020 failed with error -5
( I^2C probe for Synaptics unit fails, as expected)
...
<6>[ 9.473785] melfas_ts_probe: detected done, Operation Mode: 0x2
<6>[ 9.477783] melfas_ts_probe: sensor_rev: 0x45, hw_rev: 0x14
<6>[ 9.477813] comp_group: 0x43, fw_ver: 0x17
<6>[ 9.477813] max X size: 320, max Y size: 480
<6>[ 9.478363] input: melfas-tsi-touchscreen as /devices/virtual/input/input1
<6>[ 9.637084] melfas_ts_probe: Start touchscreen melfas-tsi-touchscreen in interrupt mode
<6>[ 9.638336] GPIO Matrix Keypad Driver: Start keypad matrix for desirec-key
pad... in interrupt mode
<6>[ 9.638519] GPIO Input Driver: Start gpio inputs for desirec-keypad... in
interrupt mode
<6>[ 9.639556] input: desirec-keypad as /devices/virtual/input/input2
So, apparently the "45_17" thing that the bootloader reports is "<hardware_rev>_<firmware_version>". The Melfas digitizer is (probably) P/N MTH-HCERB00.R14 (mfg date 8/2009), and the controller chip on the digitizer assembly has a 40-pin QFP with the ID/Datecode:
MELFAS
6SI20D
0941E
Unfortunately, nothing useful on Melfas' website that would shed any light on this.
So, anyhow...
Q: For those of you that have Melfas Touchpanels, what values do you see reported by the bootloader for hardware and firmware versions?
It's probably too much to expect to find an Eris touchpanel expert here, so instead, I'm wondering:
Q: Have any of you experienced similar issues with digitizer replacements - things that made you suspect there might be either hardware or firmware revision compatibility issues?
At this point my best guess is the problem I have is on the mobo, not the digitizer - but I can't be 100% sure, as the hw/fw revs of the digitizer could also be a wildcard. Strange, though - I don't see a peep out of the I2C kernel driver complaining about problems on that bus.
bftb0
Hmmmm.
My Eris also has the Melfas_45_17 touch panel. I wonder if the 6SI20D chip is a rebranded ARM processor, like the one mentioned in this article:?
http://mobile.arm.com/about/newsroom/25222.php?setcookie=mobile
Sent from my ADR6200 using xda premium
DrkSynDc8 said:
Hmmmm.
My Eris also has the Melfas_45_17 touch panel. I wonder if the 6SI20D chip is a rebranded ARM processor, like the one mentioned in this article:?
http://mobile.arm.com/about/newsroom/25222.php?setcookie=mobile
Sent from my ADR6200 using xda premium
Click to expand...
Click to collapse
Thanks for the reply, DrkSynDc8 (85 page views and you're the first.) I take it that your digitizer is "factory", not a replacement.
I did a little more digging - in fact, a comment by someone in the (XDA) Samsung Moment forum (!) led me to take a look at the Eris HTC kernel sources, and in fact there is special handling in the melfas_tsi.c driver code, in particular
(snippet from melfas_tsi.h)
Code:
#define MELFAS_TRIANGLE_PATTERN 0x41
#define MELFAS_DIAMOND_PATTERN 0x45
(snippet from melfas_tsi.c)
Code:
if (ts->wake_up && (ts->sensor_revision == MELFAS_DIAMOND_PATTERN)) {
So, I suppose (if the sensor rev is printed in hex by the bootloader - i.e. "45") that this indicates that I have no reason to suspect this particular hardware - there is "sensor_revision" handling in the HTC driver code to handle this specific version (and nothing other than a print statement for the firmware rev), so that's conclusive evidence that HTC was building with this digitizer. Everything else about the digitizer seems reasonable - the manufacturing date is two months before the Eris first shipped.
As for the Melfas chip (and the link you provided, thanks) - the ARM "cores" are licensed as IP cores; ARM doesn't physically produce any chips themselves. So, yeah - there might be an ARM core in there, along with the analog circuitry for driving/detecting the passive panel's capacitive sensors. Too bad Melfas doesn't provide data sheets.
The odd thing about this (the fact that the replacement unit acts squirelly) is that the "interface" being disconnected at the digitizer flex-cable connector is an I^2C bus interface plus power/ground for digitizer circuit(s). I would think that if something were wrong on the mobo side of the connector, I would see the kernel barking about I^2C problems. (I suppose a degraded power/ground connection could muck up the analog side of things without affecting the I^2C interface.)
The only other thing that I suppose could be a possibility is a stray charge / grounding issue with the digitizer screen itself. I replaced the gummy, black, factory adhesive with double-sided tape. Makes me wonder if that gummy, black goo is slightly conductive, since the bond is made to an aluminum frame in the front assembly; otoh, I haven't seen any reports about problems from other folks who used superglues or other non-conducting cementing methods when they replaced digitizers.
cheers
bftb0
PS. A little off-topic, but in my digging around, I fooled around with ".idc" files, and concluded via experimentation that (for CCM7_v18 GB, anyway) that
/system/usr/idc/melfas-tsi-touchscreen.idc
is the correct location for the Input Manager's device-specfic "device calibration" file for the melfas-tsi-touchscreen driver.
But, without further digging, I am not sure that the Input Manager's behavior (see getInputDeviceCalibration() in com.android.server.InputManager) is anything more than a stub for this particular device - it will read java name/value pairs out of that file, but I don't know (a) whether anything is done with them or (b) what the appropriate name/value pairs would be for the melfas-tsi device.
bftb0 said:
Thanks for the reply, DrkSynDc8 (85 page views and you're the first.) I take it that your digitizer is "factory", not a replacement.
I did a little more digging - in fact, a comment by someone in the (XDA) Samsung Moment forum (!) led me to take a look at the Eris HTC kernel sources, and in fact there is special handling in the melfas_tsi.c driver code, in particular
(snippet from melfas_tsi.h)
Code:
#define MELFAS_TRIANGLE_PATTERN 0x41
#define MELFAS_DIAMOND_PATTERN 0x45
(snippet from melfas_tsi.c)
Code:
if (ts->wake_up && (ts->sensor_revision == MELFAS_DIAMOND_PATTERN)) {
So, I suppose (if the sensor rev is printed in hex by the bootloader - i.e. "45") that this indicates that I have no reason to suspect this particular hardware - there is "sensor_revision" handling in the HTC driver code to handle this specific version (and nothing other than a print statement for the firmware rev), so that's conclusive evidence that HTC was building with this digitizer. Everything else about the digitizer seems reasonable - the manufacturing date is two months before the Eris first shipped.
As for the Melfas chip (and the link you provided, thanks) - the ARM "cores" are licensed as IP cores; ARM doesn't physically produce any chips themselves. So, yeah - there might be an ARM core in there, along with the analog circuitry for driving/detecting the passive panel's capacitive sensors. Too bad Melfas doesn't provide data sheets.
The odd thing about this (the fact that the replacement unit acts squirelly) is that the "interface" being disconnected at the digitizer flex-cable connector is an I^2C bus interface plus power/ground for digitizer circuit(s). I would think that if something were wrong on the mobo side of the connector, I would see the kernel barking about I^2C problems. (I suppose a degraded power/ground connection could muck up the analog side of things without affecting the I^2C interface.)
The only other thing that I suppose could be a possibility is a stray charge / grounding issue with the digitizer screen itself. I replaced the gummy, black, factory adhesive with double-sided tape. Makes me wonder if that gummy, black goo is slightly conductive, since the bond is made to an aluminum frame in the front assembly; otoh, I haven't seen any reports about problems from other folks who used superglues or other non-conducting cementing methods when they replaced digitizers.
cheers
bftb0
PS. A little off-topic, but in my digging around, I fooled around with ".idc" files, and concluded via experimentation that (for CCM7_v18 GB, anyway) that
/system/usr/idc/melfas-tsi-touchscreen.idc
is the correct location for the Input Manager's device-specfic "device calibration" file for the melfas-tsi-touchscreen driver.
But, without further digging, I am not sure that the Input Manager's behavior (see getInputDeviceCalibration() in com.android.server.InputManager) is anything more than a stub for this particular device - it will read java name/value pairs out of that file, but I don't know (a) whether anything is done with them or (b) what the appropriate name/value pairs would be for the melfas-tsi device.
Click to expand...
Click to collapse
I always need an energy drink after reading your posts, sir Good stuff though!
I've been working on fixing this issue for awhile. Here's the deal:
The problem.
The four keys at the bottom of the phone are monitored by a melfas touchkey chip (http://www.melfas.com/english/touch/sensor.asp) that connects to the main processor via an I2C bus (http://en.wikipedia.org/wiki/i2c). The melfas chip generates an interrupt whenever one of the keys is touched or released. The processor then reads the key value from this chip over the i2c bus. The problem is that the touchkey chip is located right next to the 3G antenna. When the phone is accessing the 3G network the RF energy gets transferred to the interrupt and i2c clock and data lines causing false interrupts to occur. The processor responds to the interrupt by reading the key value from the cypress chip. The symptoms occur more frequently in low signal areas because the phone outputs a higher RF level in those situations which causes more RF interference on the interrupt line.
Most of the time when a false interrupt has occurred the touchkey chip will return a value of zero for the key and the driver will recognize this as a bad key press and ignore it. Sometimes the RF interference on the i2c clock and/or data line causes a valid value to be returned and the driver reports a key press value to the application. In the case where the driver reports a ‘back’ key down, the software sees this as holding the back key down so when you press the power button you get a screen shot. The easiest way to cure this is to always press and release the back key before pushing the power button. This causes the software to see both a key down and key up event which cancels the screenshot mode.
This RFI induced touchkey interrupt happens hundreds of times per second when the phone is using 3G. It produces lots of different symptoms including applications that always seem to shut down. A wide variety of problems can be attributed to this failure. In addition, the processor spends a lot of time servicing these bogus interrupts, which take cpu time away from the other applications. This can make the phone appear to be slow or even freeze up for short periods of time. There’s a good chance that most people have experience this to some degree without realizing the root cause.
Solution one. Fix the driver.
Since this is a true hardware failure, a software solution is going to be less than perfect. After dozens of experiments rewriting the interrupt service routines in the driver I’ve settled on a combination of fixes. The first is to re-test the interrupt input line several times. In normal operation when you touch or release a button, the touchkey chip drives the interrupt line low and keeps it low until the driver reads data over the i2c interface. Since the RF interference is a sine wave and is being sampled it causes the interrupt line to go high and low at a fast rate. Sampling the line multiple times in software increases the chance of finding it in the high state. This is done both in the interrupt handler and then again in the interrupt thread. About 90% of the false interrupts are filtered out by testing the line in the handler. If the interrupt handler doesn’t find the line high after 10 samples, it masks the interrupt so that another falling edge doesn’t produce another interrupt. In testing I’ve noticed that the interrupt handler would run multiple times before the interrupt thread was even called. Once in a while, so many interrupts would get stacked up that the phone would just reboot. It was probably a stack or buffer overflow that wasn’t being handled. Remember, this interrupt would happen many hundreds of times a second. About 90% of the remaining false interrupts are filtered out by sampling this line in the thread. That leaves about 1% of the interrupts that need to be further tested. The second test is to read the data from the chip and discard anything that isn’t a valid key press value. This is easily done with a case statement. Finally, since occasionally a bogus valid value will get through, I set up a timer so that any key down event that doesn’t have a corresponding key up event within 3 seconds is canceled by calling the all_keys_up routine.
This combination all but eliminates the symptoms produced by this failure. The only draw back is that the processor still spends a considerable amount of time servicing the false interrupts. And rarely a phantom keypress does get through. In all, it’s a fairly good piece of duct tape and JB Weld.
During my experiments I used a copy of the kgb kernel. My version with the modified driver is in github at https://github.com/dmriley/kgb. If you want to try this yourself, be sure to use the ‘dev’ branch.
Solution two. Fix the hardware.
There are three signals that connect from the melfas touchkey chip to the processor. They are the two i2c lines: sdc which is the clock and sda which is the data. The third line is the interrupt. In troubleshooting this problem, I took my phone apart and put oscilloscope probes on the three lines. This allowed me to see the real cause of the problem. Since the interference is RFI (or EMI) the only real way to fix the problem is to either remove the RF or make the impedance of the signals much lower. Removing the RF is easy if you don’t need to use 3G. When the phone is using wifi (or no network connectivity at all) the problem does not exist. Also, when you are very close to a cell tower, the phone transmits at a much lower level. This lower level greatly reduces the RFI. Lowering the impedance is a little harder. I2C uses active pull down and passive pull up for the logic levels for both sda and sdc. This means that the impendence is mostly governed by the pull up resistor. This resistor value is typically upwards of 1kohm and probably as high as 3kohms (I didn’t measure it in this phone). Since the impedance only needs to be lowered for the 3G frequencies of around 800MHz, a capacitor can be added from the signal source to signal ground. At 800MHZ a 100 pf cap is about 2 ohms (1/ 2*pi*f*c). That’s a couple of orders of magnitude lower than the pull up resistor alone, and much too low for the RF signal to induce any significant voltage on the line. This value is also low enough not to interfere with the signal rise and fall times for the interrupt line. In the case of the interrupt line, the melfas chip drives the signal low and keeps it low until the interrupt is serviced. Discharging a 100pf cap with a 2mA driver takes only microseconds. This much delay is not noticeable when touching the key and is much less than the amount of time that the processor takes to service the interrupt.
Adding the cap to the interrupt line eliminates false interrupts. A chance does exist that a valid key event during 3G access could cause an incorrect key value to be returned due to RFI on the clock and data lines. The i2c protocol is designed to compensate for capacitive loading on the lines. Although it would cause the clock period to be stretched out significantly it would still only take milliseconds to read the key data from the chip. The difference would be imperceptible. To date I have only added the cap to the interrupt line and have yet to experience an invalid key press.
I’ll post pictures of cap mod.
Summary.
Most people will be satisfied using the software fix. I think that a couple of the kernel devs are incorporating some or most of the driver mods outlined in this document. Both comradesven (kgb dev) and ssewk2x aka Efpophis (glitch dev) were involved in the test and debug process. Much appreciation is given to both of them for the help that they gave me and for allowing me to use and hack up their code on github. Efpophis saved me hours of searching through code. Without their help, I’d still be unable to build a kernel.
UPDATE:30 Mar 2012
The phone had been working fine since the mod. I hadn't seen a screen capture or any of the other symptoms. Then, a couple of nights ago, while I running maps on 3G (a data intensive app) the touchkey backlights started flashing rapidly like the phone was having a little seizure. And then it happened, the voice search popped up. A couple of debug kernels later I've come to the conclusion (and I'm never wrong) that the clock line (SCL) going to the melfas chip was being toggled by the same RF interference that was causing the false interrupts. A random clock along with random data was causing the chip to turn the backlights on and off as well as generate a false interrupt. I was able to reliably duplicate the problem in a couple of really low signal level areas (not hard to find when you live out in the boonies).
I tore the phone apart (again) today and added a 100pf cap to the scl line right next to the chip. I also added another cap in parallel with the 100pf on the interrupt line. I spent about 1/2 hour tonight running 3G data apps in the same location where the problem first appeared. So far, no problems and none of the debug messages have shown up on dmesg.
If anyone wants pics of the added cap I'll open it back up, no problem, otherwise if you look at this photo you can see which pin is scl (although I incorrectly labeled it SDC in the photo). http://forum.xda-developers.com/attachment.php?attachmentid=953824&d=1332117055
If anyone tries these mods I'd be real interested in your results.
Here are some pictures of the cap mod:
this is the open phone showing where the melfas touchkey circuit is:
View attachment 951774
Awesome, thanks for doing this for all of us. Phantom key press is really annoying
Sent from my SCH-I500 using XDA App
the cap. yeah, that's a normal size pen to show scale
View attachment 951812
on the board
View attachment 951821
with notes
View attachment 951820
the antenna problem
View attachment 951822
close up showing touckey circuit. micro sd card for scale
View attachment 951834
my finger
View attachment 951836
back off
View attachment 951838
another view
View attachment 951837
BTW, I took these pictures with my son's fascinate
Wow, we're lucky to have someone as capable as yourself figure out this annoying issue! I've kinda kept up on your work, but seeing this breakdown and the photos is helpful in understanding the root cause of the problem. I do wonder sometimes how Samsung missed this issue in their testing, but at least we have custom kernels that implement your fixes and dramatically reduce the phantom presses!
Uuuhm...You're an awesome human being. Holy crap. -_-
That's some amazing work, thanks!
k_nivesout said:
.... I do wonder sometimes how Samsung missed this issue in their testing, but at least we have custom kernels that implement your fixes and dramatically reduce the phantom presses!
Click to expand...
Click to collapse
Yeah, it's crying shame that Samy couldn't fork over the extra penny to keep this problem from happening in the first place.
sendan said:
Uuuhm...You're an awesome human being. Holy crap. -_-
That's some amazing work, thanks!
Click to expand...
Click to collapse
wasn't just me. had help from other members here. I didn't even know where to start looking when I first started. It's so cool that people are willing to do the level of work that the devs here do without expecting anything back.
electric bill said:
wasn't just me. had help from other members here. I didn't even know where to start looking when I first started. It's so cool that people are willing to do the level of work that the devs here do without expecting anything back.
Click to expand...
Click to collapse
Thanks so much for all the work, and the detail in your post. It is amazing the work everybody does here and the knowledge you pass on to us.
I do have a few questions
Would you mind sharing what kind off iron you used? is that the most bottom line on the board you soldered to? If so, did you have to scratch it or something first? Is it the farthest left line on the chip that was used? Do they make caps that size with leads coming of the 2 sides, and if so would that be a easier mod? Is there a positive and negative side to that capacitor?
I'm really thinking about doing this, if i decide to would you mind sending me 5 of your extra caps for a $10 donation?
Sent from my SCH-I500 using xda premium
Ditto on the $10.00
neh4pres said:
Thanks so much for all the work, and the detail in your post. It is amazing the work everybody does here and the knowledge you pass on to us.
I do have a few questions
Would you mind sharing what kind off iron you used? is that the most bottom line on the board you soldered to? If so, did you have to scratch it or something first? Is it the farthest left line on the chip that was used? Do they make caps that size with leads coming of the 2 sides, and if so would that be a easier mod? Is there a positive and negative side to that capacitor?
I'm really thinking about doing this, if i decide to would you mind sending me 5 of your extra caps for a $10 donation?
Sent from my SCH-I500 using xda premium
Click to expand...
Click to collapse
I did the mod at my workplace under a microscope. I used a metcal (http://www.okinternational.com/product_soldering/mx500) soldering iron but you could use just about any low wattage iron with a really fine tip.
There's four pins on each side of the melfas chip. One end of the cap is soldered right to the interrupt pin which is the closest to the corner. the other end is connected to the ground side of C2 via a solder bridge.
View attachment 953824
I doubt that they make caps that small with leads on them. You could look. It's not hard to make the solder bridge. Remember the scale that were talking about here. That cap is 0.06 inches long by 0.03 inches wide. I wouldn't try to scratch the solder resist from the board because it's a flex circuit on top. Also, the cap is not polarized.
I bought a hundred of these caps for less than $6 including shipping. I'd feel terrible charging someone $10 for five. If you pm me your address I'll stick a couple in an envelope and send them. If you want to give away ten bucks, donate it to a charity like destiny rescue or UMCOR (http://new.gbgm-umc.org/umcor/about/financialinformation/).
Disclaimer:I've been working with parts this size for years and am pretty good at soldering. You risk dorking up your phone if you don't do this correctly. Only attempt if you are skilled at soldering. All information is presented "as is" and without warranty for fitness or use. Your mileage may vary. Void where prohibited, taxed or licensed.
What is the easiest way to implement the band-aid software fix?
I am on CSpire so there are not many proven custom roms out there.
IamUmpire57 said:
What is the easiest way to implement the band-aid software fix?
I am on CSpire so there are not many proven custom roms out there.
Click to expand...
Click to collapse
The fix is in the kernel. I used the KGB kernel as the source for my build. You can download it from github and build your own. If you're running all stock (rom & kernel) you can mod the stock kernel.
I'm really not the expert here on choices. Maybe someone else could chime in.
Too tiny to solder so band-aid?
Excellent research, fix and documentation. I was going to follow the fix, but, when I finally got the phone disassembled, I saw that the bits were much too small for me to solder. And I'm an ex-electronics guy who's worked on surface mount stuff before, so I doubt amateurs will have much luck, either.
So the problem is that RFI is hopping onto the I2C and interrupt lines... Could we just block the RFI? Sure. A grounded piece of aluminum foil which covered the whole Melfus+lines area should do that. So I tried that. Worked great for the soft keys, but, for reasons not apparent to me, my phone would no longer do 3G (stuck in 1X). Perhaps because the big old piece of grounded foil in the middle of the 3G antenna soaked up too much signal?
How about not grounding the Aluminum foil? It wouldn't be tied to ground, so the potential of the Alu foil would wobble, but it might prevent enough RFI from reaching the I2C and interrupt lines.
I opened the phone back up and squished the Alu foil a bit so that it just covered the Melfus chip and the lines heading to the left, and so that it didn't touch what-I-think-is the ground plane right at the upper edge of the PCB. Now, the piece of Alu foil was a rectangle about 6mm wide and 3mm tall. Seems to prevent softkey misfires and my phone seems more responsive. Assuming the results hold, this is a 5 minute fix for the issue and it doesn't require anything more than a tiny screwdriver, a spot of aluminum foil and a moderately steady hand. Wish me luck!
CoffeeDregs said:
Excellent research, fix and documentation. I was going to follow the fix, but, when I finally got the phone disassembled, I saw that the bits were much too small for me to solder. And I'm an ex-electronics guy who's worked on surface mount stuff before, so I doubt amateurs will have much luck, either.
So the problem is that RFI is hopping onto the I2C and interrupt lines... Could we just block the RFI? Sure. A grounded piece of aluminum foil which covered the whole Melfus+lines area should do that. So I tried that. Worked great for the soft keys, but, for reasons not apparent to me, my phone would no longer do 3G (stuck in 1X). Perhaps because the big old piece of grounded foil in the middle of the 3G antenna soaked up too much signal?
How about not grounding the Aluminum foil? It wouldn't be tied to ground, so the potential of the Alu foil would wobble, but it might prevent enough RFI from reaching the I2C and interrupt lines.
I opened the phone back up and squished the Alu foil a bit so that it just covered the Melfus chip and the lines heading to the left, and so that it didn't touch what-I-think-is the ground plane right at the upper edge of the PCB. Now, the piece of Alu foil was a rectangle about 6mm wide and 3mm tall. Seems to prevent softkey misfires and my phone seems more responsive. Assuming the results hold, this is a 5 minute fix for the issue and it doesn't require anything more than a tiny screwdriver, a spot of aluminum foil and a moderately steady hand. Wish me luck!
Click to expand...
Click to collapse
That's great work. I tried that initially with some foil tape over the whole melfas chip without success. This was all documented in the github problem log but it got deleted when the ticket was closed out. In my basement where I was doing my testing, the signal strength is very low so it's a worst case scenario. Maybe the shield will work better if it's shaped just right. I'm not an RF guy so my shield was just a guess. Share some pics with us if you find a solid solution. The shield would be much easier to implement.
electric bill said:
I tried that initially with some foil tape over the whole melfas chip without success.
Click to expand...
Click to collapse
What was not successful about it? You still had phantom keypresses or you lost 3G?
Also, how did you ground the foil? I grounded it against what I thought was a ground plane. And I covered the entire L-shaped assembly (Melfas, lines and all).
[Stating the obvious...:] The idea of covering the Melfas chip and lines with foil assumes that the RFI is getting to the lines from above the chip+lines. The foil wouldn't do anything were the RFI hopping over from elsewhere. But AFAICT the top layer of the PCB is a ground plan and the signal lines head down into buried layers directly from the connector, so I'm not sure how else RFI could get the I2C lines except from in the module...
My un-grounded foil seems to be an improvement, but not a fix, so I might try grounded-foil again and try to figure out why it killed my 3G.
Good to hear that you have a microscope; I still have 20/20 vision as a 40yo, but that's a tiny little area!
I gotta say that I am wildly disappointed in Samsung. If a few electronics-savvy folks polking around the interwebs can find root cause and propose multiple fixes, it's shocking that Samsung won't acknowledge it, much less fix it. I'm due a phone upgrade and I'd love to get an SGS III, but I really don't trust Samsung.
CoffeeDregs said:
What was not successful about it? You still had phantom keypresses or you lost 3G?
Also, how did you ground the foil? I grounded it against what I thought was a ground plane. And I covered the entire L-shaped assembly (Melfas, lines and all).
[Stating the obvious...:] The idea of covering the Melfas chip and lines with foil assumes that the RFI is getting to the lines from above the chip+lines. The foil wouldn't do anything were the RFI hopping over from elsewhere. But AFAICT the top layer of the PCB is a ground plan and the signal lines head down into buried layers directly from the connector, so I'm not sure how else RFI could get the I2C lines except from in the module...
My un-grounded foil seems to be an improvement, but not a fix, so I might try grounded-foil again and try to figure out why it killed my 3G.
Good to hear that you have a microscope; I still have 20/20 vision as a 40yo, but that's a tiny little area!
I gotta say that I am wildly disappointed in Samsung. If a few electronics-savvy folks polking around the interwebs can find root cause and propose multiple fixes, it's shocking that Samsung won't acknowledge it, much less fix it. I'm due a phone upgrade and I'd love to get an SGS III, but I really don't trust Samsung.
Click to expand...
Click to collapse
Yeah, I used what I thought was a ground pad and covered pretty much everything on that little flex board that has the chip on it. It didn't stop the problem. Also, I had a bunch of dmesg stuff in the driver so I could see every time that there was a "missfire" vs just seeing the actual symptoms. A shield could theoretically fix the problem, I'm just not a RF engineer so I went with what I know. With the microscope, it's pretty easy to add the caps. Without, it'd be kinda hard. It probably only took me 20 minutes or so to do the last one I did. The good news it, the cap fix does the trick 100%. We've been running it on three phones without a problem for a few months now.
I totally agree on Samsung's failure. That design defect should have been caught pretty early in development. Maybe these guys have never heard of a Peer Review . It's even sadder if they knew it might be a problem but decided to risk it to save 1/2 cent per phone.
I understand the corporate mentality of denying a problem exists (iphone signal loss is a good example). If they admit it, then they have to fix it and that would be very costly. I'm sure when they started to have a problem they did a cost analysis and decided that losing N number of customers was cheaper than actually fixing all the bad phones.
What made it even worse was trying to find info on the phone design. Samsung was completely unresponsive when I contacted them to get data sheets on the CPU and other info on the phone. It's as if they didn't want me to solve the problem. Come to think of it, they probably didn't want me to. Solving it verifies that the problem exists and isn't just user error.
Anyway, now with my phone fixed and the excellent AOKP ROM and Glitch kernel, I love my fassy.
electric bill said:
Yeah, I used what I thought was a ground pad and covered pretty much everything on that little flex board that has the chip on it. It didn't stop the problem. Also, I had a bunch of dmesg stuff in the driver so I could see every time that there was a "missfire" vs just seeing the actual symptoms. A shield could theoretically fix the problem, I'm just not a RF engineer so I went with what I know. With the microscope, it's pretty easy to add the caps. Without, it'd be kinda hard. It probably only took me 20 minutes or so to do the last one I did. The good news it, the cap fix does the trick 100%. We've been running it on three phones without a problem for a few months now.
I totally agree on Samsung's failure. That design defect should have been caught pretty early in development. Maybe these guys have never heard of a Peer Review . It's even sadder if they knew it might be a problem but decided to risk it to save 1/2 cent per phone.
I understand the corporate mentality of denying a problem exists (iphone signal loss is a good example). If they admit it, then they have to fix it and that would be very costly. I'm sure when they started to have a problem they did a cost analysis and decided that losing N number of customers was cheaper than actually fixing all the bad phones.
What made it even worse was trying to find info on the phone design. Samsung was completely unresponsive when I contacted them to get data sheets on the CPU and other info on the phone. It's as if they didn't want me to solve the problem. Come to think of it, they probably didn't want me to. Solving it verifies that the problem exists and isn't just user error.
Anyway, now with my phone fixed and the excellent AOKP ROM and Glitch kernel, I love my fassy.
Click to expand...
Click to collapse
Yeah: dmesg would be lots better!
My foil status: decent. I'm getting a lot less buzzing, but I still do get **some** in low signal areas (my bedroom). So I'm happier.
Samsung's response: I'm not at all surprised. I used to be an FAE for Cirrus Logic and worked a lot with ARM processors (back in 2000-2003). I got ahold of some of Samsung's datasheets on their ARM processors and was staggered: the datasheet was about 4 pages long and was full of errors, inaccuracies or glossings-over. Our datasheets were 40 pages long and we had 200 page programming manuals available on the web. You got no love from Samsung unless you were looking to buy 5M chips.
Anyways, thanks for you research and help!
I'll be giving that kernel a shot!
Second cap
I finally got around to mod'ing our last phone. Actually, I was finally able to pry it from my teen's hands long enough to do the work. I think she sat home all afternoon and twitched.
Anyway, here's a pic of the two caps. One is on the interrupt line and the other is on the clock (or scl) line. I melted the insulation from a piece of real fine magnet wire to connect between the clock pin and the second cap. The other end of the second cap is just solder bridged to the same ground as the first cap.
We are in the process of developing a *Mezzanine* board for 96boards CE SBCs. The purpose of this board is to implement the complete interface between the standardized SBC, and pretty much any car.
*Note: This is not a feature discussion thread, the features are set, the prototypes are built, painstakingly by hand over many hours.
The mezzanine board has the following (primary) features;
Quad-stereo ADC,
2 stereo DAC with programmable DSP (also has a header for up to 2 more DACs for up to 8 channel audio),
AMFM Radio,
OEM-style class AB automotive amplifier (4x52 watt @ 4 ohm, 4x85 watt @ 2 ohm),
ATSAMD21 microcontroller for SWI, fan control (fan is not mandatory), backlight control, etc.,
Physical interface to a conventional vehicle specific automotive pigtail.
This would be the additional component recommendation (and we are also considering a KIT):
1) 96boards CE SBC. We have a current working prototype using a Hikey960 (4xA73 + 4xA53, 4 GB), and are in the process of obtaining a Dragonboard 820C (2x Kryo big + 2x Kryo little, 3 GB). Note that some CE SBCs may not have full compatibility due to lacking the optional digital audio input pin. These two I've mentioned have *FULL* compatibility, and we are providing software support.
2) An HDMI monitor with USB touchscreen. There are tons of options for these, including ones packed in a DDIN chassis.
3) A USB GPS (you can get really good ones for as little as $10). Note that the dragonboard 820c has a built-in GPS, although I haven't tested its performance.
4) A pigtail (sometimes called a "wiring harness") for your specific vehicle.
** you can also add a USB HUB and any number of UVC cameras for dashcam and/or parking assistance.
96boards is a specification for SBCs developed by Linaro. Linaro is one of the big promoters and developers of Linux based operating systems, including Android/AOSP. So what you get with this, is the ability to build the complete operating system for your car radio **from source**. Hikey960's device repository is hosted by Google and is listed as an official "Reference Board". The Dragonboard 820C's device tree is in heavy development and is not quite ready to merge, but is available on Linaro's repositories, and from what I'm told, is functionally in a very good state.
In addition, since we are interfacing with SBCs having a standardized interface, when the boards we are currently working with become dated (as everything eventually does), you can easily replace the SBC with a new one that is completely up to date, while retaining the Mezzanine that actually interfaces with the car.
We have also developed additions to the Hikey960 kernel and Android device tree for supporting our mezzanine board and enabling the Automotive features of AOSP. And yes, our additions are all open source, which means that you can build it all yourself.
We have not yet set a price point for the board, but I can tell you that it will not come cheap. The component and manufacturing cost is quite extensive. Our objective, however, is to provide two things to make up for that, which you simply can't get anywhere else;
1) A "high end" experience that is significantly higher than the expensive mainstream car radios (kenwood, pioneer, etc.)
2) Full control over the software, including complete source code. No locks on the hardware. No or minimal blobs. The Hikey960 runs on a single blob for the Mali GPU. The Dragonboard 820C runs on NO blobs -- it uses the Freedreno graphics driver.
Features of our prototypes;
1) Navigation. Uses Google Maps / Waze or any other nav software.
2) Hands free calling.
3) AMFM Radio.
4) Bluetooth music.
5) Dashcam.
6) Its running AOSP 8.1 -- the sky is the limit.
Also worth mentioning:
*** Designed in Canada.
*** Made in Canada or USA. Depends on how the pricing works out.
So, who is interested? What would you pay?
No support for lvds for the LCD? That would eliminate needing an HDMI converter.
It's also seems off that as designers you did not ask for input from the one community who this is targeted to, XDA...the point is to dig into the market currently dominated by the poor quality ODMs of Chinese head units.
Pricing...if it works well $300 to $500for the mezz and hikey as a bundle??? The dragon board is not interesting....you can't even run android on that. The hikey960 and 970 is a better choice, especially the 970 once things get going since it has GPS!
gtxaspec said:
No support for lvds for the LCD? That would eliminate needing an HDMI converter.
It's also seems off that as designers you did not ask for input from the one community who this is targeted to, XDA...the point is to dig into the market currently dominated by the poor quality ODMs of Chinese head units.
Pricing...if it works well $300 to $500for the mezz and hikey as a bundle???
Click to expand...
Click to collapse
LVDS is really not a viable option, because every different display will require extensive work to support, as well as, in many cases, a custom physical interface. If the goal was a single fixed product in a black box, then I would consider LVDS.
As a developer, I built it because I enjoy working on it. If I can sell it, so much the better.
96carboard said:
LVDS is really not a viable option, because every different display will require extensive work to support, as well as, in many cases, a custom physical interface. If the goal was a single fixed product in a black box, then I would consider LVDS.
As a developer, I built it because I enjoy working on it. If I can sell it, so much the better.
Click to expand...
Click to collapse
Makes sense! Well, great work anyways. Are we going to see any pictures anytime soon??? I have some empty 2 din cases,and A hikey960 I would love to try this on
gtxaspec said:
Makes sense! Well, great work anyways. Are we going to see any pictures anytime soon??? I have some empty 2 din cases,and A hikey960 I would love to try this on
Click to expand...
Click to collapse
I should have my next batch of prototypes (bare circuit boards) late next week or early the week after. I can post pics of the bare board, but if you're asking for pics of an assembled prototype, I'd rather not post pics of the currently running one on account of it really *looking* like a prototype (there are a few "corrections" on it).
Maybe what I'll do, is take pictures of one as I'm assembling it. I'm sure that some people would find it fascinating.
96carboard said:
I should have my next batch of prototypes (bare circuit boards) late next week or early the week after. I can post pics of the bare board, but if you're asking for pics of an assembled prototype, I'd rather not post pics of the currently running one on account of it really *looking* like a prototype (there are a few "corrections" on it).
Maybe what I'll do, is take pictures of one as I'm assembling it. I'm sure that some people would find it fascinating.
Click to expand...
Click to collapse
Very cool! If you need someone to test, always willing! I currently work on some ROMs for the Chinese based unita, but an opensource aosp unit has always been the goal (*_*)
So. Ils possible use stock screen from golf mk7 facelift with your headunit?
I'm very interested. It's something that i'm looking for a while now and will be willing to pay high-end price for high-end performance.
But it also need to be high-end "experience"... Meaning it requires a good looking radio app, physical volume control etc.
I would be also interested the hear about the display option that you found and how "high-end" this could be in term of screen quality but also dash integration?
Anyway, the mezzanine itself would be a huge step forward and I will frequently follow the 96boards website to see when it will be available.
A huge thanks for all the work you already did!
ti-b said:
I'm very interested. It's something that i'm looking for a while now and will be willing to pay high-end price for high-end performance.
But it also need to be high-end "experience"... Meaning it requires a good looking radio app, physical volume control etc.
I would be also interested the hear about the display option that you found and how "high-end" this could be in term of screen quality but also dash integration?
Anyway, the mezzanine itself would be a huge step forward and I will frequently follow the 96boards website to see when it will be available.
A huge thanks for all the work you already did!
Click to expand...
Click to collapse
The radio application is the AOSP automotive radio application https://android.googlesource.com/platform/packages/apps/Car/Radio/. How it looks really is between you and google. The objective, as far as software is concerned, is to change as little as possible with respect to AOSP. As far as physical volume controls go, the buttons on your steering wheel will work, or any other buttons, knobs, switches, or whatever else you might want to hook up.
First Assembly photo
Since I've got the software into a pretty good state now for running the previous board revision, I've now begun assembling my "V1.0". This revision is "very close" to what I will be shipping.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This board measures 123x78mm (under 5x3 inches).
U101 is a 3.3v very low dropout linear voltage regulator. It is used for powering all of the 3.3v components on the board, notably, the analog sides of all of the audio chips, which require a very clean and stable power supply, which is why its an LDO and not a buck.
Q101 is an N-FET, which controls the inhibit pin of the LDO. It takes input from either the microcontroller or the ignition signal. If they *both* switch off, then the LDO also switches off. D101 is a diode that prevents the microcontroller's output pin that drives Q101 from feeding to its input pin that reads the ignition signal.
U102,3,4 are optocouplers, used to read input signals from the car, which can vary within the range of 8-18 volts (though typically will be in the range of 11-15) and convert them into signals that are safe for the microcontroller and/or CPU. All three feed input pins to the CPU, U102 also feeds an input to the microcontroller.
The differences between this board and the final shipping board will be these;
1) There will be a 5th pin at J101, which will be connected to the "switched 12V output" of U203.
2) There will be two 3A diodes between the power input pins and J101.
** Together, these two changes will allow the board to be setup in a mode that allows the CPU and/or microcontroller to control power-off. J101 is a jumper block that allows the user to choose the mode of powering the system.
3) R203/204 are removed, since they are unnecessary.
4) The Anode of D701 is changed from 1.8v to 3.3v. This is to improve i2c performance of U701 (real time clock) and increase the charge on C701 (to increase the time the RTC can run for before the supercapacitor drains).
5) A zener diode is connected from the PWM pin of the fan plug to GND. This is to protect the microcontroller from excessive voltage that may be output by poor quality or incompatible fans. A good quality 5V PWM fan (like a Noctua) will pull the PWM pin up to no more than 3.3v. In fact, I checked with Noctua, and they pull it up to 2.5v. A low quality (cheap) fan may save a resistor by pulling it up to 5v, or a 12v fan could pull it up to anywhere between 3.3 and 12v. A 12v fan should not be used, but I'm sure that someone will plug one in anyway.
96carboard said:
Since I've got the software into a pretty good state now for running the previous board revision, I've now begun assembling my "V1.0". This revision is "very close" to what I will be shipping.
This board measures 123x78mm (under 5x3 inches).
U101 is a 3.3v very low dropout linear voltage regulator. It is used for powering all of the 3.3v components on the board, notably, the analog sides of all of the audio chips, which require a very clean and stable power supply, which is why its an LDO and not a buck.
Q101 is an N-FET, which controls the inhibit pin of the LDO. It takes input from either the microcontroller or the ignition signal. If they *both* switch off, then the LDO also switches off. D101 is a diode that prevents the microcontroller's output pin that drives Q101 from feeding to its input pin that reads the ignition signal.
U102,3,4 are optocouplers, used to read input signals from the car, which can vary within the range of 8-18 volts (though typically will be in the range of 11-15) and convert them into signals that are safe for the microcontroller and/or CPU. All three feed input pins to the CPU, U102 also feeds an input to the microcontroller.
The differences between this board and the final shipping board will be these;
1) There will be a 5th pin at J101, which will be connected to the "switched 12V output" of U203.
2) There will be two 3A diodes between the power input pins and J101.
** Together, these two changes will allow the board to be setup in a mode that allows the CPU and/or microcontroller to control power-off. J101 is a jumper block that allows the user to choose the mode of powering the system.
3) R203/204 are removed, since they are unnecessary.
4) The Anode of D701 is changed from 1.8v to 3.3v. This is to improve i2c performance of U701 (real time clock) and increase the charge on C701 (to increase the time the RTC can run for before the supercapacitor drains).
5) A zener diode is connected from the PWM pin of the fan plug to GND. This is to protect the microcontroller from excessive voltage that may be output by poor quality or incompatible fans. A good quality 5V PWM fan (like a Noctua) will pull the PWM pin up to no more than 3.3v. In fact, I checked with Noctua, and they pull it up to 2.5v. A low quality (cheap) fan may save a resistor by pulling it up to 5v, or a 12v fan could pull it up to anywhere between 3.3 and 12v. A 12v fan should not be used, but I'm sure that someone will plug one in anyway.
Click to expand...
Click to collapse
This looks exciting. Lot's of effort resulting in an Android system that is put together the way it should be. Many kudos.
If you are looking at making some changes you could save some cash by dropping the optocouplers. I know that it sounds like the craziest idea ever but I swear all you need to protect a MCU pin from the outside automotive world is a 220k resistor and a 100nF cap. Cap is on the side of the pin, resistor connects to the outside world. When I first started work at an automotive dev company I saw this arrangement and nearly fell off my seat. Turns out that almost every single MCU/CPU/device with an IO pin out there has a very simple protection cct on each pin which consists of two internal diodes per pin. Anode on the pin with cathode to VCC for the high side protection, anode on 0V and cathode on the pin for the low side protection. Some manufacturers just used a single zener with the anode on 0v and the cathode on the pin and this offered both high and low side protection. By putting the signal from the car through the 220k you technically are driving the pin such that the protection circuit is coming into play but the energy that you are driving into the circuit is SO low that the diode easily handles it and the VCC rail just sinks the tiny current elsewhere. The cap is there to protect against induced noise and very low energy but high voltage spikes that may appear on the input line. I was skeptical until I learned that this had been used on a high seller that was installed into over 3 million vehicles... After working there for 8 years I had designed it into every product I worked on and swore by it. Maybe give it a try. I swear it won't disappoint.
By far the largest killers of products that I found was overshoot caused by jump starting and installers making silly mistakes. Installers would often connect outputs directly to the items they were meant to drive instead of going through a relay first. Ever tried driving a horn with a FET? We ended up using some pretty neat protected FETs to solve this but they were costly. Another common installer error is incorrect polarity on the power lines or on the IGN/ACC line. Simply solved by putting diodes in series with the VCC and IGN/ACC inputs. The jump start issue was more tricky to solve. At first we were using a MOV based circuit to try and absorb the energy from the spike and it would often work but it was costly and too "soft" in the turn on conditions which led to it sometimes not working as desired. We eventually moved across to a solution which was dirt cheap but absolutely brilliant in how well it worked. It was just a BJT, a FET and a few passives around them. As soon as the input voltage exceeded a certain rate of change (early warnings of a large incoming spike) or a certain voltage then it would completely cut power to the rest of the board for the duration of the spike. In the end the only limit to the level of spike it could handle was the reverse voltage of the FET body diode. The circuit passed all OEM load dump tests and is operating in several hundred thousand cars today. The only downside to it was that your product would lose vehicle power during a load dump condition and need to rely on an internal battery to continue operating. Since jump starting or any load dump condition is very infrequent this was not much of a negative for our applications.
looxonline said:
This looks exciting. Lot's of effort resulting in an Android system that is put together the way it should be. Many kudos.
If you are looking at making some changes you could save some cash by dropping the optocouplers. I know that it sounds like the craziest idea ever but I swear all you need to protect a MCU pin from the outside automotive world is a 220k resistor and a 100nF cap. Cap is on the side of the pin, resistor connects to the outside world. When I first started work at an automotive dev company I saw this arrangement and nearly fell off my seat. Turns out that almost every single MCU/CPU/device with an IO pin out there has a very simple protection cct on each pin which consists of two internal diodes per pin. Anode on the pin with cathode to VCC for the high side protection, anode on 0V and cathode on the pin for the low side protection. Some manufacturers just used a single zener with the anode on 0v and the cathode on the pin and this offered both high and low side protection. By putting the signal from the car through the 220k you technically are driving the pin such that the protection circuit is coming into play but the energy that you are driving into the circuit is SO low that the diode easily handles it and the VCC rail just sinks the tiny current elsewhere. The cap is there to protect against induced noise and very low energy but high voltage spikes that may appear on the input line. I was skeptical until I learned that this had been used on a high seller that was installed into over 3 million vehicles... After working there for 8 years I had designed it into every product I worked on and swore by it. Maybe give it a try. I swear it won't disappoint.
By far the largest killers of products that I found was overshoot caused by jump starting and installers making silly mistakes. Installers would often connect outputs directly to the items they were meant to drive instead of going through a relay first. Ever tried driving a horn with a FET? We ended up using some pretty neat protected FETs to solve this but they were costly. Another common installer error is incorrect polarity on the power lines or on the IGN/ACC line. Simply solved by putting diodes in series with the VCC and IGN/ACC inputs. The jump start issue was more tricky to solve. At first we were using a MOV based circuit to try and absorb the energy from the spike and it would often work but it was costly and too "soft" in the turn on conditions which led to it sometimes not working as desired. We eventually moved across to a solution which was dirt cheap but absolutely brilliant in how well it worked. It was just a BJT, a FET and a few passives around them. As soon as the input voltage exceeded a certain rate of change (early warnings of a large incoming spike) or a certain voltage then it would completely cut power to the rest of the board for the duration of the spike. In the end the only limit to the level of spike it could handle was the reverse voltage of the FET body diode. The circuit passed all OEM load dump tests and is operating in several hundred thousand cars today. The only downside to it was that your product would lose vehicle power during a load dump condition and need to rely on an internal battery to continue operating. Since jump starting or any load dump condition is very infrequent this was not much of a negative for our applications.
Click to expand...
Click to collapse
It sound like you're describing the ESD diodes. Some might consider it slightly abusive to apply them in this manner, but I can definitely appreciate the application.
While I do know that the SAMD has this sort of arrangement on its input pins, I'm not sure whether this arrangement is present on the SoC or not -- my guess is probably NOT, and even if it is, I definitely can NOT trust that all 96boards SBCs will be equally protected. Only one of the optocouplers is even connected to the SAMD (the bottom one, IGN), all 3 optocouplers are connected to the SoC. If you will notice, there are two voltage dividers on the output of the bottom optocoupler -- R104/107 divides 5 volts down to 1.8 for the CPU, R113/114 divides 5 volts down to 3.3 for the microcontroller.
think widely
I suggest you to take a look at taho screen they don't replace the stereo they add a box that work as android with the oem stereo see youtube most of the new cars now a days comes with touch screen think widely take a look of the possibilities good luck
I will become a locale official vendor (if it has a affordable price and a excellent android support)
najaray said:
I suggest you to take a look at taho screen they don't replace the stereo they add a box that work as android with the oem stereo see youtube most of the new cars now a days comes with touch screen think widely take a look of the possibilities good luck
I will become a locale official vendor (if it has a affordable price and a excellent android support)
Click to expand...
Click to collapse
There would be nothing stopping you from using a built-in screen with this, as long as the built-in screen has an HDMI input -- which frankly, is quite unlikely, so I wouldn't get my hopes up.
In any case, that decision is outside of the scope of my project. The selection of display device would be up to whoever is installing it.
96carboard said:
There would be nothing stopping you from using a built-in screen with this, as long as the built-in screen has an HDMI input -- which frankly, is quite unlikely, so I wouldn't get my hopes up.
In any case, that decision is outside of the scope of my project. The selection of display device would be up to whoever is installing it.
Click to expand...
Click to collapse
I see it means that some of the customer like tahoe for example cannot use this product at all can you verify the cars that your targitting
can it run two screens at the same time like screen 1 for the stereo and a screen 2 for the car dashboard
najaray said:
I see it means that some of the customer like tahoe for example cannot use this product at all can you verify the cars that your targitting
Click to expand...
Click to collapse
I don't know what you mean by "tahoe" or "taho" as per your previous spelling, but it sounds to me like your questions are off topic. If you wish to continue this, please do so via PM.
looxonline said:
The jump start issue was more tricky to solve. At first we were using a MOV based circuit to try and absorb the energy from the spike and it would often work but it was costly and too "soft" in the turn on conditions which led to it sometimes not working as desired. We eventually moved across to a solution which was dirt cheap but absolutely brilliant in how well it worked. It was just a BJT, a FET and a few passives around them. As soon as the input voltage exceeded a certain rate of change (early warnings of a large incoming spike) or a certain voltage then it would completely cut power to the rest of the board for the duration of the spike. In the end the only limit to the level of spike it could handle was the reverse voltage of the FET body diode. The circuit passed all OEM load dump tests and is operating in several hundred thousand cars today. The only downside to it was that your product would lose vehicle power during a load dump condition and need to rely on an internal battery to continue operating. Since jump starting or any load dump condition is very infrequent this was not much of a negative for our applications.
Click to expand...
Click to collapse
Wouldn't all of these problems be solved with a TVS diode?
https://www.littelfuse.com/~/media/...utomotive_tvs_diodes_application_note.pdf.pdf
96carboard said:
Wouldn't all of these problems be solved with a TVS diode?
https://www.littelfuse.com/~/media/...utomotive_tvs_diodes_application_note.pdf.pdf
Click to expand...
Click to collapse
Yup, that's similar to the MOV solution. The problem with this type of solution is that it can create the clamp but it can't absorb all of the energy from the load dump (some, yes but not all). It therefore requires somewhere to dump the energy and that somewhere is in the resistance within the alternator and in the leads to the product. Our products could be installed in any location within the vehicle and in a huge variety of vehicles. Controlling the resistance between the alternator and the MOV (in our case) was impossible and this is one of the reasons why the MOV solution was abandoned. Another reason was cost. For a MOV that could handle the variation in conditions that our products were exposed to we had to go for a relatively high power variant. These could cost upwards of $2 which was insanity when you are talking about designing that into a circuit that is selling in excess of 60k units per month. The cut off circuit cost a fraction of that and so we ran with it
Fully operational: