Hi,
In our current research, we want to measure power consumption of an I9250 doing various network related tasks. To do this, one of our electronic wizards must connect his instrumentation tools to the battery pinouts. He told me he needed to know the resistance of the two extra pins (those two except + and -)
Anyone who knows this, or has done something similar?
Best wishes,
Morty
So as I understand it those are not used to provide power for the battery. These other pins are used to communicate with the battery (and if it has NFC) use the antenna embedded into the battery. Your engineer doesn't need to do anything with these but connect them straight to the phone.
Out of curiosity is your research going to get published anywhere? I am really interested in those types of numbers
Hi thanks!
We did similar test on the Nokia N900. For this phone, we had to add resistance to the third pin (the additional to + and -). The results are not published, it was part of a master thesis for one of our students.
The experimentation with the nexus is also part of a master thesis, as always we hope it will end with a publication! We can then provide some results.
Well I don't understand why they need to do anything, if they pass these straight through and tap the power lines the battery should work fine (appear transparent).
If that doesn't work then you have two options. The first thing is to buy a replacement battery and take it apart. The second would be to go into your lab and use a scope/meter to measure those lines and see what they do.
I'm working on a system for my vehicle which needs a device that has Bluetooth and at least one (preferably a couple) "thing" (GPIO or useless LED or whatever) that I can have an application set and hold to either high or low. The device needs its own battery, so that it can operate without draining the vehicle's battery. What I'm ultimately trying to do, among other things, is to use Blueooth proximity detection to unlock my car - and a bunch of other things while the car's on. Because cell phones (and, to a lesser extent, tablets) already have batteries that will last for days with all the radios shut down, the screen off, apps suspended, and the CPU in a low-power mode, that seems an ideal approach - made better because older phones cost near-nothing on eBay. I don't have to have a visible display, but a working touchscreen would simplify a lot of other things I'd like to do.
But it seems darn near impossible to figure out what device would be be appropriate. Specifically, I haven't been able to find a good way to identify what devices have something like unused / repurposable GPIOs. I don't know if I need to just repurpose an LED, or if there are phones (or tablets) which already have something to interface with. Or if there are newer devices that I can use something like a USB serial port on, or if I just play a "sound" which makes the audio output seem to be "on", or what. The important thing is that the phone/tablet has to be self-contained, as charger power will be disconnected when the vehicle is off - and it'd be best if I could get an extended-use battery for this device which could maximize availability while the vehicle is parked (likely for several days). Since that covers just about every phone, the next most important thing is to figure out how to make it interface with the outside world without the outside world needing to provide any additional power to enable that communication (i.e. I can turn on a transistor, but I can't have something like the daisy bluetooth GPIO devices running as that will use car battery power).
So, I guess I'm asking how people usually interface with the outside world using a hard-wired connection, and what devices to look for (or how to identify those devices) which make that relatively easy. Can someone get me pointed in the right direction? I'm currently just wandering the web trying to find a starting point, and since the odds are good that this forum is going to be a stop somwehere along the path anyway, I figured this'd be a good start.
dannysauer said:
... What I'm ultimately trying to do, among other things, is to use Blueooth proximity detection to unlock my car - and a bunch of other things while the car's on...
Click to expand...
Click to collapse
What other things? And what do you mean by proximity detection? You want it to unlock your car automatically, as soon as your phone is in range or is it ok if you have to run an app and press "unlock my car" button?
qubas said:
What other things? And what do you mean by proximity detection? You want it to unlock your car automatically, as soon as your phone is in range or is it ok if you have to run an app and press "unlock my car" button?
Click to expand...
Click to collapse
I mean "poll bluetooth and unlock when I'm near". If I have to push a button, I may as well use a regular keyless entry fob.
While the car's running, I'd like to be able to run some standard apps, like an mp3 player, Wigle wifi scanner (presuming I find something w/wifi and gps) , and similar standard car pc stuff. That's all easy, though. And the programming to poll bluetooth is not that hard (I'd probably just use llama to start with). The hard part for me is really just how to hard wire a relay or transistor, and get a program to turn it on or off.
In that case you should think about IOIO (google "IOIO for Android"), it gives you a lot of digital I/O and analog input pins.
I have an idea for a project that requires a large panel to be attached to a small phone, does any one know if this is possible.
I know from previous projects that the galaxy line phones seem to have similar cables and connectors but , for example, could I plug a note screen into a GS2? I know the ribbons wont be in the right place and it will be bodged together but that isn't important. What is important is will they physically connect??
My hardware knowledge is good but by software side not so good. I know that android is capable of adapting to different resolutions but will this work "out the box" or will the resolution need changing in the build,prop, or maybe more??
any ideas on this please share, I think this is quite an exciting project that I will share and colabarate with if it is feasable. Its still at the rough concept stage at the moment and I am just checking out the theory behind it so please share your knolage and experience
Possible, but not easy
add.thebad said:
I have an idea for a project that requires a large panel to be attached to a small phone, does any one know if this is possible.
I know from previous projects that the galaxy line phones seem to have similar cables and connectors but , for example, could I plug a note screen into a GS2? I know the ribbons wont be in the right place and it will be bodged together but that isn't important. What is important is will they physically connect??
My hardware knowledge is good but by software side not so good. I know that android is capable of adapting to different resolutions but will this work "out the box" or will the resolution need changing in the build,prop, or maybe more??
any ideas on this please share, I think this is quite an exciting project that I will share and colabarate with if it is feasable. Its still at the rough concept stage at the moment and I am just checking out the theory behind it so please share your knolage and experience
Click to expand...
Click to collapse
It is feasible, lots of screens use similar interfaces (parallel TTL, MIPI, LVDS, etc.) so the trick is finding a display with the same interface as your phone already has. You will then need to make a board to adapt from the flex cable you have to the flex cable on your new screen. On that board you will probably also need to provide power since the new screen will consume more power. You will then need to modify the kernel, bootloader and Android to set the correct timing and resolution. (Timing, pinout and resolution for Linux kernel and U-Boot and resolution and DPI for Android) Shoot me a PM, I do this kind of stuff as a consultant and I am happy to give you some pointers!
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: