HeroC's speaker jack vs GPIO - Hero CDMA General

Does anybody happen to know how the HeroC's 1/8" jack is connected to the MSM 7600A inside the Hero? Is there an amplifier circuit buffering it, or are one or two of its pins wired straight to pins on the 7600A? Does it have 2 contacts + ground (mono headphone + mic), or does it have 3 contacts + ground (1 for mic, 2 for stereo, the second of which is ignored when a normal headset is used)? Is there a datasheet somewhere online?
Why? If the headphone jack is wired straight to the 7600A, there's a very, very good chance it can be used for general purpose i/o, above and beyond merely driving a speaker and sampling a microphone. God forbid, if it has 3 signals + ground, we're talking bitbanged SPI. If someone at HTC and/or Qualcomm had a sense of humor, and picked GPIO pins with I2C as a secondary function, well... that would just be pure bliss

no way we're talking spi...I mean just no way...I hope I'm wrong lol

I am not sure what all this means but it sounds exciting. I found a pic of it dissasembled but not a great shot of the headphone jack. Hope it helps.

Well, SPI would mainly depend upon having a 4-contact headphone connector (purely speculating, I put the likelihood at around 30%). All you need to make SPI work is one pin that can be configured as input (MISO) and two pins that can be configured as output (MOSI and SCK).
I2C almost certainly wouldn't be do-able unless some engineer at Qualcomm LITERALLY paired DO and DI as secondary functions for i/o pins suitable for DAC & ADC use as well, and someone at HTC happened to pick the same two pins to use for the headphone jack. On the other hand, if the headphone jack has only 3 contacts (2 i/o + ground), that would guarantee that at least one of them IS bidirectional-capable, because it would have to do double-duty as a PWM-output device AND a voltage comparator (so it could drive one of two stereo headphone drivers, sample the mic of a phone headset, and simultaneously allow the chip to detect when the pin got shorted to ground by the user pressing the 'answer' button.
If nothing else, it could probably do not-quite-I2c-kind-of-ghetto-half-duplex-SPI, using one pin as an output clock, and using the other for input or output as necessary. The nice thing about SPI is that if you're interfacing to your own stuff, the timing can be totally brutal, sloppy, and bitbanged (take SCK high, set MOSI, take SCK low, sample MISO, stir, rinse, & repeat a few billion times)
I'm putting the odds that the headphone jack is connected straight to the 7600A at around 40%. Normally, any sane design would buffer something like an audio circuit so something really bad wouldn't damage the CPU as well... but we're talking about a phone that's basically irreparable by human hands if anything on the board fries anyway, so the real-world advantage of external buffering would be countered by real-world savings from pulling as much external circuitry into the controller as possible.

bitbang3r said:
Well, SPI would mainly depend upon having a 4-contact headphone connector (purely speculating, I put the likelihood at around 30%). All you need to make SPI work is one pin that can be configured as input (MISO) and two pins that can be configured as output (MOSI and SCK).
I2C almost certainly wouldn't be do-able unless some engineer at Qualcomm LITERALLY paired DO and DI as secondary functions for i/o pins suitable for DAC & ADC use as well, and someone at HTC happened to pick the same two pins to use for the headphone jack. On the other hand, if the headphone jack has only 3 contacts (2 i/o + ground), that would guarantee that at least one of them IS bidirectional-capable, because it would have to do double-duty as a PWM-output device AND a voltage comparator (so it could drive one of two stereo headphone drivers, sample the mic of a phone headset, and simultaneously allow the chip to detect when the pin got shorted to ground by the user pressing the 'answer' button.
If nothing else, it could probably do not-quite-I2c-kind-of-ghetto-half-duplex-SPI, using one pin as an output clock, and using the other for input or output as necessary. The nice thing about SPI is that if you're interfacing to your own stuff, the timing can be totally brutal, sloppy, and bitbanged (take SCK high, set MOSI, take SCK low, sample MISO, stir, rinse, & repeat a few billion times)
I'm putting the odds that the headphone jack is connected straight to the 7600A at around 40%. Normally, any sane design would buffer something like an audio circuit so something really bad wouldn't damage the CPU as well... but we're talking about a phone that's basically irreparable by human hands if anything on the board fries anyway, so the real-world advantage of external buffering would be countered by real-world savings from pulling as much external circuitry into the controller as possible.
Click to expand...
Click to collapse
could you put that in english please. LOL just teasing bro

I'm an computer engineering student and you just threw me for a loop. I think what you're trying to say is that if what you think is going on is that it might be possible to use the phone as a microcontroller or have controls like media playback go through the jack. Am I wrong? Just trying to put in non-engineer language.

SPI is basically a shift register protocol. It allows a master to communicate with one (possibly more, if you have additional lines to do addressing) slave(s). The master controls the clock. When the clock is low (ground), the slave is allowed to read the MOSI (Master Out, Slave In) signal, and the master is allowed to read the MISO (Master In, Slave Out) signal. When the clock pin is high (traditionally 5v, but 3.3v, 3.0v, 2.7v, and even lower signal levels are common now), the master and slave aren't allowed to read, and instead take advantage of the opportunity to change the state of their respective output lines to reflect the value of the next bit they want to send.
The main advantage of having a line dedicated to a clock is that you don't have to worry about timing if you're the slave. You don't have to count milliseconds while a pin is high or low. You just watch the clock, read when it goes low, and write when it goes high.
I've also seen circuits that went a step further, and used a MOSI transition while SCK was low (normally taboo) to signal the start of a new byte. In situations like that, if you were the slave, you'd sit there and wait for SCK to go low, then you'd wait until MOSI changed state while SCK was low. From that point, you'd know that it's time to send and receive the next byte.
Most people who get into robots start with serial ports because they're easier to interface with computers, but when you're wiring devices together without a computer in between and basically just bitbanging (taking advantage of the fact that modern processors are so fast compared to what existed 20 years ago, you literally CAN get away with just tapping your foot and busy-waiting while counting clock cycles, and faking out the signals that used to take real hardware to do.

Long story short, He is hoping that the headphone jack is connected straight to the IC so it could possibly be used as a data connection (think kinda like a modern day serial port) if it is.Aiming towards SPI with a smallpossibility of I2C. Exampals
I2C is use by wiimote's to connect to the nunchuck or the motionplus
SPI is used by alot of LCD segmant displayes ( The x3 xbox mod chip uses it for its lcd )
::edit:: didn't see your reply Bitbanger. we must have been typing at the same time

I'm an computer engineering student and you just threw me for a loop. I think what you're trying to say is that if what you think is going on is that it might be possible to use the phone as a microcontroller or have controls like media playback go through the jack. Am I wrong? Just trying to put in non-engineer language.
Click to expand...
Click to collapse
Actually, what I have in mind is a real 4-way gamepad that clamps onto the end and plugs into the headphone jack, with a 3v battery to power it and basically two i/o lines into the phone... clock and data (using something like an Atmel Tiny2313 or Mega48 to read the gamepad switches and broadcast their state to the phone using those two i/o lines).
It's something I've been toying with all the way back to my Samsung SPHi300, but I've always run into insurmountable hardware problems along the way (besides the lack of a 3D printer to make the prototype itself, of course). My i300 had a real serial port and a nice, hackable Dragonball that gave me warm fuzzy m68k feelings of joy, but you couldn't buy a connector for it to save your life, and Samsung's cables were obscenely expensive until long after the i300 faded from view. The SPHi500 would have been perfect with a thumb-operated gamepad in one hand, and the phone (using the keypad for fire buttons) in the other, but it only had USB. I tried IrDA, but Samsung's PalmOS4 ROM was a hacked-up mess. My PPC6700 had a semi-usable joystick, and architecturally was totally alien to me anyway. By the time I got my Touch, I was more comfortable with ARM, but HTC took away the IR and WiFi, leaving only USB and bluetooth. USB was out of the question, and the cheapest bluetooth module you could buy from Sparkfun was about a hundred bucks (I came close to breaking down a few times, though). I was about to finally buy one of their new ~$30 modules to use with my Hero before Christmas, until I found out that phones with 1.5 couldn't use the Android Bluetooth API. Let's just say I think the entire neighborhood heard me shouting obscenities in the general direction of HTC and Sprint when I realized that I couldn't do a thing bluetooth-wise until I had 2.x in my hands

Related

mapping hardware for this device

Hi all,
As i started servicing all pdas for a couple of monthes (only as a hobby, i fix them for friends and relatives), i came across one BA that gave me some trouble.
i got it to replace its LCD that was broken as it was dropped and thats very simple to replace it, so far so good. now it has two main problems :
1. no sound from speaker (even when in speakerphone mode), but there is sound in the stereo earphones (i plugged to the connector by the sd card slot). - i can only assume that a bluetooth handsfree device it will also work.
2. although the backup battery is fully charged, if i remove the main battery even for a brief second, when turned on, the BA acts as if i made a hard reset.
as for solving the problems :
1. using a digital multimeter, i managed to track the conductivity from the internal speaker through its connector, flat ribbon to the connector which connects to the main pcb - so there is no contact problem from the speaker to the main pcb.
using the help from WIKI, i went to site that has the list of all components and their description - the IC that is responsible for audio amp is a MAXIM's MAX4410 which is a stereo headphone driver. a quick look at its charasteristics and typical configuration and i understood that (assuming this is the IC that drives the internal speaker) the speaker should have one pin which is ground and the other goes to the amplified signal from the IC. neither one of the pins showed it has GND to it. so maybe there is a bad GND line to the connector.
2. regarding the backup battery issue i do not know what makes this problem.
I am sharing this info with you all with two ideas in mind :
1. to resolve my problem and know those devices hardware better.
2. because i am quite a while watching xda-developers and WIKI and i got the feeling that a lot of eforth is given to the software side of all those pdas (which is greate!!! keep going, this work helps lots of people and it shows al thos mega corps they are not the only ones), but the hardware is a bit forgotten and left behind. let me tell you this, there are many VERY simple mini projects i made useing electronics (i am an electronics engineer in my profession) that made my life easy . i am now investigating those instruments hardware as i have several ideas to develope useful accessories to my pda (like an external IR transciver to control IR devices like TV,DVD and to communicate with my laptop, and some other ideas) and i believe we can do the same info sharing as done on software side but on the hardware side.
I will thank any ideas, thoghts or commentsabout this matter. Yol.
i suspect you confuse ppl by mentioning BA in your post but writing your post in more then 1 forum not related to BA if BA == blue angel

mapping hardware for this device

Hi all,
As i started servicing all pdas for a couple of monthes (only as a hobby, i fix them for friends and relatives), i came across one BA that gave me some trouble.
i got it to replace its LCD that was broken as it was dropped and thats very simple to replace it, so far so good. now it has two main problems :
1. no sound from speaker (even when in speakerphone mode), but there is sound in the stereo earphones (i plugged to the connector by the sd card slot). - i can only assume that a bluetooth handsfree device it will also work.
2. although the backup battery is fully charged, if i remove the main battery even for a brief second, when turned on, the BA acts as if i made a hard reset.
as for solving the problems :
1. using a digital multimeter, i managed to track the conductivity from the internal speaker through its connector, flat ribbon to the connector which connects to the main pcb - so there is no contact problem from the speaker to the main pcb.
using the help from WIKI, i went to site that has the list of all components and their description - the IC that is responsible for audio amp is a MAXIM's MAX4410 which is a stereo headphone driver. a quick look at its charasteristics and typical configuration and i understood that (assuming this is the IC that drives the internal speaker) the speaker should have one pin which is ground and the other goes to the amplified signal from the IC. neither one of the pins showed it has GND to it. so maybe there is a bad GND line to the connector.
2. regarding the backup battery issue i do not know what makes this problem.
I am sharing this info with you all with two ideas in mind :
1. to resolve my problem and know those devices hardware better.
2. because i am quite a while watching xda-developers and WIKI and i got the feeling that a lot of eforth is given to the software side of all those pdas (which is greate!!! keep going, this work helps lots of people and it shows al thos mega corps they are not the only ones), but the hardware is a bit forgotten and left behind. let me tell you this, there are many VERY simple mini projects i made useing electronics (i am an electronics engineer in my profession) that made my life easy . i am now investigating those instruments hardware as i have several ideas to develope useful accessories to my pda (like an external IR transciver to control IR devices like TV,DVD and to communicate with my laptop, and some other ideas) and i believe we can do the same info sharing as done on software side but on the hardware side.
I will thank any ideas, thoghts or commentsabout this matter. Yol.
It seems you have posted this in more than 5 different forums topics.
This will not get you an answer quicker. Please, as this is a BA device, would it be possible to just keep the posts either in the BA topics or in the Upgrading, modifying, unlocking topic.
Please don't feel insulted, it's just that some people use the "view posts since last visit" and saw 8 instances of the same message.
Anyway, to your problem:
1. I guess it is best if you do try first if the bluetooth has sound. If it does, maybe it is the speaker, if not maybe the sounds are set to off for phone sounds. Check the volume slider.
2. Can't help you with the battery problem, sorry

mapping hardware for this device

Hi all,
As i started servicing all pdas for a couple of monthes (only as a hobby, i fix them for friends and relatives), i came across one BA that gave me some trouble.
i got it to replace its LCD that was broken as it was dropped and thats very simple to replace it, so far so good. now it has two main problems :
1. no sound from speaker (even when in speakerphone mode), but there is sound in the stereo earphones (i plugged to the connector by the sd card slot). - i can only assume that a bluetooth handsfree device it will also work.
2. although the backup battery is fully charged, if i remove the main battery even for a brief second, when turned on, the BA acts as if i made a hard reset.
as for solving the problems :
1. using a digital multimeter, i managed to track the conductivity from the internal speaker through its connector, flat ribbon to the connector which connects to the main pcb - so there is no contact problem from the speaker to the main pcb.
using the help from WIKI, i went to site that has the list of all components and their description - the IC that is responsible for audio amp is a MAXIM's MAX4410 which is a stereo headphone driver. a quick look at its charasteristics and typical configuration and i understood that (assuming this is the IC that drives the internal speaker) the speaker should have one pin which is ground and the other goes to the amplified signal from the IC. neither one of the pins showed it has GND to it. so maybe there is a bad GND line to the connector.
2. regarding the backup battery issue i do not know what makes this problem.
I am sharing this info with you all with two ideas in mind :
1. to resolve my problem and know those devices hardware better.
2. because i am quite a while watching xda-developers and WIKI and i got the feeling that a lot of eforth is given to the software side of all those pdas (which is greate!!! keep going, this work helps lots of people and it shows al thos mega corps they are not the only ones), but the hardware is a bit forgotten and left behind. let me tell you this, there are many VERY simple mini projects i made useing electronics (i am an electronics engineer in my profession) that made my life easy . i am now investigating those instruments hardware as i have several ideas to develope useful accessories to my pda (like an external IR transciver to control IR devices like TV,DVD and to communicate with my laptop, and some other ideas) and i believe we can do the same info sharing as done on software side but on the hardware side.
I will thank any ideas, thoghts or commentsabout this matter. Yol.
I think you should post this again, just in case we missed the other 9 duplicate posts... wouldn't this have made most sense in the development and hacking section, pretty much the only section you didn't post to?
V
@Vj LOL
Fault 1) When I hear someone saying 'maybe it has a bad earth' i think of car mechanics 'wiring' and Ford cars! If you have the data sheet, use a 'scope - fixing it should be a piece of cake (IF you know what you are doing)
Fault 2) These devices usually have tiny 3V Li-ion button batteries somewhere inside - find it, replace it.
BTW - search the internet for a SERVICE MANUAL - you NEVER know your luck!
Andy
Fault one the backup battery is designed to keep memory alive not power the unit! I would expect it to act the way you describe.
Audio check the stereo jack, my guess is you'll find the problem there. It's rather common failure.
I never said the battery backup powered the unit, did I? He said removing the main battery & putting it back in acts like a hard reset indicative of a knackered memory backup battery.
I'm making educated guesses based on 15 years experience as an electronics engineer & also that I have just fixed an Xda Exec with EXACTLY this problem (If I'm reading his post correctly that is).
Andy

SM-G900T snapdragon to Android streaming box? Using internal video output

Ok, so i have my Galaxy S5 tmobile that ive been playing with recently. awhile ago i tried to replace the rear facing camera, and the loudspeaker. unfortunatly when removing the screen, the digitizer was damaged. oled was working great. i would just use a bt mouse to navigate. well last night i pulled the phone apart to compare the amoled connection to that of a S7. just to see if i could throw the S5 screen onto my broken S7 to attempt to setup screen mirroring to my tv and be able to use it with a keyboard and mouse for general streaming.
I left the screws out of the midframe assembly of the S5 and it fell off the table after being reasembled. (love when the pets get into my workshop)
anyway, it was just enough to crack the very corner of the OLED and now there is no functionality to the screen.
ive been thinking about trying something that i just havent seen before, and cant find any information on at all.
There has got to be a way to take the ribbon cable from the S5 screen with the connector and splice/solder into some kind of digital video output. also the audio to the loudspeaker adjusted to low-line and connected alongside the digital video to make a single digital A/V output.
Basically i want to have my BT keyboard and mouse and be able to have it outputting video to either a Moniter, tv, wireless adapter of some sort. i would leave the OS pretty much the same minus alot of needless software at that point, and be able to turn essentially any tv with HDMI or digital video in, into an android smart tv..
i have arduino uno kits and Abillion cables of all sorts.
if anyone has any insght to the format of video coming from the OLED connector, or a pinout , any information that would help me get the ball rolling on this. i would be extremely grateful.
"_Gears Always turning, on your voy-age to droid-age_"
Don't like MHL adapters for some reason?
bbsc said:
Don't like MHL adapters for some reason?
Click to expand...
Click to collapse
They are nice and all. But that would mean I would have to spend money on something to make it work... Also mhl adapters take their own power supply at 5.0v, which means it would have to be plugged in somewhere during its use. Which I had planned on just using a couple 8000 mAh lithium batteries wired in parallel to power the phone at 3.7v. Getting me somewhere between 6 to 8 days of heavy usage before a recharge. And would make it much more portable.. Maybe even construct a small enclosure with a fan out of one of my CCTV cameras. Even if I had to convert the video and audio signals using a microprocessor, I wouldn't have to spend a dime doing the entire project if it works the way Im imagining it too. One of my main objectives with this project is to use parts from old equipment that I already have.
This is more about doing something creative and new with old Galaxy phones that have no other practical use.
Yes I could order an android box off amazon for less than 20$ and do what everyone else did to stream...
Yes I could order an mhl cable and set it up that way....
Yes I could put a new display assembly on it and use it for dev....
But if everyone thought like that, android wouldn't have existed in the first place.

RFC / Feeler: AOSP custom car radio

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:

			
			
			
			
			
			
			
			
			
			

			
		

	
	
	



	
	







			

		



		

			
Categories

			
		


		

			
Resources