Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Page 10 of 18 < 1 2 ... 8 9 10 11 12 ... 17 18 >
Topic Options
#370154 - 15/12/2017 01:58 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Mmmm.. I suppose one might have gotten the wrong pin -- the labeling on the board is really poor on that side. RST is the 7th pin.

Quote:
Voltage measured at Betz 3v3 pin: 183mv
.

That's a decent sign actually. Might just be a dead regulator, which isn't really a catastrophe here. Those are cheap and not too difficult to replace.

I still haven't figured out how this board should be wired, but they definitely took a few short-cuts. Mine behaves better now with the slider switch in the position furthest from the USB connector. The Arduino reset takes care of things nicely there.

Top
#370155 - 15/12/2017 01:59 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
Tried a crazy idea. Attached the Lithium battery from the BlueGiga dev board to the battery pins on the Betz breakout board.


Dangerous to have it in there charging, as we don't know yet where the fault is. If you can charge it some other way, and then power the board with just the battery, that could tell us something.

Top
#370156 - 15/12/2017 02:12 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Can you explain more what your thinking was for the "INPUT" and "INPUT_PULLUP" modes on the reset line? I was doing some code refactoring, trying to put that code into a subroutine, and I tried different approaches to those. Perhaps I left it in the wrong mode for too long or something.
_________________________
Tony Fabris

Top
#370157 - 15/12/2017 02:48 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
I was just trying to avoid having to have a pair of resistors similar to the serial pin. It is okay to drive LOW (ground) on the reset pin, but NOT okay to drive HIGH (+5V) on that pin.

Since the Arduino has an internal pull-up resistor available (INPUT_PULLUP), I used that instead of "HIGH". A pull-up is just a suitable resistor (eg. 50-100K-ohm) connected between the pin and +5V internally. It would still give +5V for a very weak current draw, but won't pass enough current to harm stuff.

When the pin is later programmed to plain "INPUT", it actually has a very very weak pull-down (to ground) resistance.

So the simple code I supplied just puts a high pulse onto the reset pin for a few hundred milliseconds, and then pulls the pin down to ground and leaves it there.

Safe so long as one never drives HIGH on that pin.

Cheers

Top
#370158 - 15/12/2017 02:52 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
And in order to drive it high, it would need to have been set to OUTPUT, right? Something I didn't do.

I may have left the pin in INPUT or INPUT_PULLUP for longer than 300ms. would either of those have hurt it?

In other news:

I tried powering the Betz board with about 3.2v coming out of the "3v" pin on the arduino and into the "3v3" pin on the Betz board, with the 5v pin disconnected from the Betz board. Didn't solve the problem and the board was dark.
_________________________
Tony Fabris

Top
#370159 - 15/12/2017 02:55 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
If I power both the 5v and 3v3 pins on the Betz board it light up. Trying to see if it works normally now.
_________________________
Tony Fabris

Top
#370160 - 15/12/2017 02:58 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
And the web site still shows version 523.


v523 was new today. That's the one.

Top
#370161 - 15/12/2017 03:00 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
I thought that the issues I was reporting were with V523. Though now I must retry because now I'm not sure any more. smile

In the meantime: Powering both 5v and 3v3 pins on the Betz board makes my chip work, but it gets warm. Warmer than I expect it to get, though not scalding. Warmer than I recall it getting before.

Do you think that's an issue?
_________________________
Tony Fabris

Top
#370163 - 15/12/2017 03:04 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
The board would need to be somewhat rewired in order to operate it with straight 3.3V. Which is a shame, because the WT32i module itself would be quite happy with 3.3V.

But the way they've wired things doesn't adapt nicely to it. And for such a simple schematic, they've really gone out of their way to make it difficult to read! Especially the power wiring.

Top
#370164 - 15/12/2017 03:13 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Actually, I don't think you can hurt much stuff with both 5V and 3.3V fed to the board. The voltage regulator might go up in smoke, but I think the rest is okay so long as the FTDI chip isn't powered up. And even it might be fine.

The VDD_IN pin of the WT32i connects directly to the "3.3V" pin, and that's perfectly safe to do. I'm just not understanding the VDD_CHG and VDD_BAT pins, and what should really be done with those. The datasheet gives a couple of suggestions, but my head hurts and I'm retiring for the night now.

Cheers




Edited by mlord (15/12/2017 03:15)

Top
#370165 - 15/12/2017 03:18 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
OK thanks for all your help! smile
_________________________
Tony Fabris

Top
#370166 - 15/12/2017 03:51 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
More information:

Since the chip seemed to get warm when I connected 3.3v, I looked at the Betz schematic, and what the schematic says it expects on that pin is actually 2.5v despite the "3v3" on the pin name. I was wondering if 3 volts was a hair too much and what I should really be trying is 2.5 volts there.

So I thought, hey, I've got 5 volts here, I can just do another 50% voltage divider to get 2.5 volts. So a couple of 10k resistors and now I had what I thought should be 2.5 volts heading into that 3v3 pin.

But that's not what I measure there. With everything hooked up, I'm getting about 60-70mv on that pin if the switch is in the down/right position, and the LED blinks steadily and the unit won't wake up. And with the switch in the up/left position, I get a varying amount in the range of 100-170mv on that pin, and the LED is dark and the unit won't wake up.

Hmph.
_________________________
Tony Fabris

Top
#370167 - 15/12/2017 04:22 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Current state:

I tried it out connecting the Betz board to both 5v and 3.3v supplies at the same time.

Chip sorta worked. It connected and exchanged data with my bluetooth headset. I could issue pause/play commands from the bluetooth headset (the only thing the headset will do).

However there was no sound. On a hunch, I hooked up some RCA plugs to the analog input pins on the Betz board and switched the line in the code to route the audio to internal instead of I2S. I got sound. Switched it back to I2S, no sound.

Also the chip keeps reporting that it's receiving random "AVRCP PAUSE" and "AVRCP PLAY" commands even though I'm not issuing them from the headset.

So I think I'm back to the state I was with the BlueGiga dev board: Fried I2S input and no idea why.

Is there a chance that we are missing some kind of buffer circuit or even simply a voltage decrease between the empeg's I2S outputs and the chip's I2S inputs?
_________________________
Tony Fabris

Top
#370168 - 15/12/2017 06:42 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
[SLEEPWALK]
I'll have a look at that (I2S) later. But I don't think there's a problem with it.

For the RST pin, the WT32i datasheet suggests a diode rather than a straight wire. This implies that the pin might also be an output from WT32i in addition to being an input.

I'll investigate that later too, but for now best to leave the RST disconnected until I've had another look on the weekend. Or if you have a general purpose small signal diode, use it. The WT32i datasheet has a diagram somewhere with the polarity.
[/SLEEPWALK]

Top
#370169 - 15/12/2017 06:52 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
hey, I've got 5 volts here, I can just do another 50% voltage divider to get 2.5 volts. So a couple of 10k resistors and now I had what I thought should be 2.5 volts heading into that 3v3 pin.

But that's not what I measure there.


Yeah. Welcome to Ohm's Law. smile
If you measure the voltage at the midpoint there with nothing else connected to the midpoint, it will read exactly half of the input voltage. But only because the voltmeter has a high impedance (resistance here), and doesn't suck more than a microamp or two.

A voltage divider (two resistors) works only for a tiny current draw. Because of Ohm's Law, a tiny current draw will still yield close to the desired output voltage. But draw more current (like.. powering a bluetooth chip with it) and E=IR says that the resulting voltage drop through the resistor will be high, leaving nearly nothing left.

Or something like that. The only way to make a resistor ladder work here is to use SMALL resistors, so that they can conduct more current with minimal voltage drop. BUT "more current" means more waste (heat) in the resistors, and that's not great either so don't do it. smile


Top
#370170 - 15/12/2017 07:10 Re: BlueGigaEmpeg [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: mlord
Originally Posted By: tfabris
hey, I've got 5 volts here, I can just do another 50% voltage divider to get 2.5 volts. So a couple of 10k resistors and now I had what I thought should be 2.5 volts heading into that 3v3 pin.

But that's not what I measure there.


Yeah. Welcome to Ohm's Law. smile
If you measure the voltage at the midpoint there with nothing else connected to the midpoint, it will read exactly half of the input voltage. But only because the voltmeter has a high impedance (resistance here), and doesn't suck more than a microamp or two.A voltage divider (two resistors) works only for a tiny current draw. Because of Ohm's Law, a tiny current draw will still yield close to the desired output voltage. But draw more current (like.. powering a bluetooth chip with it) and E=IR says that the resulting voltage drop through the resistor will be high, leaving nearly nothing left.

My sleep-impaired brain says there is a simpler (meaning, more correct) way to explain it:

The WT32i board is also a "resistor", or at least so from the point of view of its power supply. So that resistor, or "internal resistance", needs to be included in the calculation for the resistor ladder you are building. Except the WT32i is a variable resistor, having different internal resistance depending upon what it is doing at any given point.

This makes it nigh impossible to power with a resistor ladder, unless the resistors you choose for the ladder are significantly lower than the internal resistance of the WT43i, so that its resistance doesn't throw off the ladder's value too much.

Same result though: do NOT attempt this. it will likely draw too much current and fry the resistors (literally: smoke). Eg, if you used two 100ohm resistors, then even with nothing connected to their midpoint that circuit will draw (5V / 200ohms) = (0.0925amps, or 25 milliamps. The heat generated would be (5V * 0.025amps) = 1/8watt. Which is just enough to fry the typical small 1/8W resistors used with Arduinos and such.



Edited by mlord (15/12/2017 07:16)

Top
#370171 - 15/12/2017 08:29 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Get some sleep, Mark! smile

I've just wired back up the original BlueGiga dev board, this time with analog audio instead of I2S and it's working well. My original BlueGiga dev board also has no working I2S either.

I have a choice in powering this system, and I've tried both and both work, and I'm wondering what your opinion of this is:

Option 1:
- Pololu voltage regulator's 5v output goes into VIN on the Arduino which goes into the Arduino voltage regulator.
- Everything else (5V input on BlueGiga board, Max232) are powered off the 5v rail coming off of the Arduino.

Option 2:
- VIN on Arduino is not used.
- Pololu voltage regulator powers everything and connects to everything's 5v rail, including Arduino's 5V rail, Max232, BlueGiga board's 5v input, everything.

Both have worked but I don't know which is correct.
_________________________
Tony Fabris

Top
#370173 - 15/12/2017 10:33 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Mark, I hope you got some sleep. I hope I get a chance to also. smile

Thanks again for all your help with everything. You've been awesome.

Originally Posted By: mlord
v523 was new today. That's the one.


Now that I've got things working with the old BlueGiga dev board again I had a chance to retest V523. (Well I stayed up past 2am to get the assembly working again and I decided to stay up a little extra to test things too.)

Here's the current issues I'm seeing with V523:

- When the player is paused, the Z (source) and D (duration) data do not come out the serial port for the current track, they come out the serial port for the next track. Repro steps: Pause player. Press Next Track. Z and D do not come out at first. Press Next Track again. Z and D come out now, but they are not for that track, they are for the previous track. On the car stereo screen, the Album title is shown that is the album title from the previously-played track while all the other track metadata is for the current track.

- When the player wakes from sleep or the player has recovered from a low voltage event, this is a fresh reboot of the Arduino and the Bluetooth chip. This can also happen when you are listening to the stereo in Accessory mode and then you start your car, causing the voltage to drop briefly. When this happens, the deduplication feature does not allow the player application to repeat its track data to the serial port (usually it does repeat it in these situations). This results in "Unknown track on Empeg Car" on the car stereo screen quite frequently. This did not occur with V522, there was always the correct track on the screen after any sorts of power events on the empeg player. Repro steps: With the player connected and playing, sleep and then wake the player from its front panel. The bluetooth will disconnect and reconnect, and when it reconnects, it will say "Unknown track on Empeg Car".

- The deduplication feature prevents me from being able to key off of any single particular piece of serial port data or even any particular sequence of serial port data (since, when paused, there are no time sequence ("#") lines coming out) to decide when I have a full track data set and can flag the host stereo that new data is available. This results in my code having to flag the host stereo for every line of new track data. For each new track this can be up to 5-7 repeated "TRACK_CHANGED" notifications instead of just one. For a single track change, or maybe two or three, this is OK, but pressing "next-next-next-next-next" on the player front panel in quick succession is enough to overload the host stereo and make it stop getting new track data altogether. This is only necessary in V523; in V522 with single notifications then the host stereo eventually caught up and multiple track changes didn't seem to confuse it.

I think the last two mean that we should go back to non-deduplicated (but keeping all your other improvements) and I'll fix the full-player-shuffle issue in a different way in the code. I think that trying to fix those last two issues would be just too complicated for Hijack and out of its scope. What do you think?

Thanks again!
_________________________
Tony Fabris

Top
#370174 - 15/12/2017 10:46 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
By the way, I have just now updated the BlueGigaEmpeg code on GitHub to be the version that works with V523. It's possible that some of the track desynchronization issues you had yesterday were due to the fact that I hadn't uploaded a version of the code that was compatible with the deduplicated Hijack version.

It also contains your Pin 51 reset line code, though it is disabled at the moment (commented out and/or with a return statement preceding it, depending on where in the code you're looking).

If you want to re-enable the reset line, look in the code for all occurrences of the variable "ResetLinePin" and make the necessary changes near those points.

Also the version up on GitHub is configured for analog input instead of I2S input at the moment, change the corresponding line if you want to switch it to I2S.
_________________________
Tony Fabris

Top
#370175 - 15/12/2017 12:53 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
When the player is paused, the Z (source) and D (duration) data do not come out the serial port for the current track, they come out the serial port for the next track.


Yeah, that makes sense. The code that outputs them doesn't have its own thread, so it cannot output anything until the next time the player sends something (anything) out the serial port. So this is only an issue WHILE PAUSED, right? If the player is actively playing, the data should arrive within a second or two. I will rearrange it to come out regardless while paused, but I do need you to confirm the current behaviour. Thanks.

Quote:
When the player wakes from sleep or the player has recovered from a low voltage event, this is a fresh reboot of the Arduino and the Bluetooth chip.

Right. So we need a way to get you a complete set of track data then. I'll work on that. Most likely, we'll just have the code send a request in on the serial port, and the result will be a full dump of track data back out.

Quote:
my code having to flag the host stereo for every line of new track data.


That is a problem. I suppose one simple solution would be to hold back all of the track data until it has all been retrieved. Or to always output the final line ('D' Duration) so you can trigger from that. This would delay updates of the headunit display for 1-5 seconds, depending on how busy/slow the hard drive is. That's because the slow part here is reading the tag file to get the Source and Duration fields. Everything else is available instantly.

Going back to dedup won't be any better for this one, other than bombarding the serial port buffers much more heavily and overflowing.

The funny thing is, hardly none of this matters for the eventual internal implementation. The full track data is always readable from /proc/empeg_notify, and it should even be possible to use poll() or select() to be auto-notified whenever it gets updated. smile But that doesn't really help with the external Arduino thing.

Cheers


Edited by mlord (15/12/2017 14:05)

Top
#370176 - 15/12/2017 13:54 Hijack v524 is released. [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Hijack v524 is now available.

-- gets rid of de-duplication of serial notification lines.

Top
#370177 - 15/12/2017 16:33 Re: Hijack v524 is released. [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
smile

Thank you! Grabbing it and installing it now.

Thank you so much for helping so much with this project. I don't think I could do this without your help.
_________________________
Tony Fabris

Top
#370178 - 15/12/2017 18:05 Re: Hijack v524 is released. [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
I have tested V524 and all the issues that I reported before are fixed. smile

Thank you!!!

Current code up at https://github.com/tfabris/BlueGigaEmpeg is written to work correctly with V524.

Changes you might need to make to get the code working for you after you download it:

- The reset line pin 51 code is disabled or commented out, search for "resetLinePin" in the code to locate all the places. I will make a note to fix this tonight, so that it's a single flag variable instead of having to fish through the code.

- The code is currently set to use analog audio instead of I2S. Search for "SET CONTROL AUDIO" to fix this if you need it fixed. I will also make a note to turn this into a flag variable.

- My code still uses a different security method than what you succeeded with. I will make a note to see if I can set it that way for my devices too, then we can both use the same security method.


I'm really interested in hearing how you are doing with this, now that you've got successful connectivity.

I have a set of PCBs on their way from Pad2Pad which should make assembling one of these devices pretty easy. I could send you one if you like! I also ordered a couple more Betz boards in case I fry more boards. smile

Thanks so much!
_________________________
Tony Fabris

Top
#370179 - 15/12/2017 18:15 Re: Hijack v524 is released. [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
My code still uses a different security method than what you succeeded with. I will make a note to see if I can set it that way for my devices too, then we can both use the same security method.


We should be able to just key off of the Manufacturer ID from the head-unit's MAC address, and then auto-select the appropriate security method based on that. The same type of identification could then be used for any other system-specific tweaks that might arise.

I believe the "3 0" method is the best, and should remain the default.

Cheers!


Edited by mlord (15/12/2017 18:31)

Top
#370180 - 15/12/2017 18:24 Re: Hijack v524 is released. [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
I'm really interested in hearing how you are doing with this, now that you've got successful connectivity.


I am not doing much with it just yet. My goal with the Arduino setup was to get the pairing working with a setup as close as possible to yours.
Now that this is happening, I am going to capture some more traces, help identify/fix any glaring issues, and then work on an empeg-only implementation for my setup.

Things are more than a bit "complicated" here just now, so it could be a while before I get back onto it again, though I do hope to try with your latest code drop ASAP.

Quote:
I have a set of PCBs on their way from Pad2Pad which should make assembling one of these devices pretty easy. I could send you one if you like!

Thanks for offering the PCBs. I'm not sure I would make much use of one though, as I will be moving the Betz board inside the empeg sometime in the next couple of months. [EDIT]For now I have just hot-melt glued both the Arduino and the WT32i to the top of the empeg. smile[/EDIT]
Quote:
I also ordered a couple more Betz boards in case I fry more boards. smile

Ah yes, we do have to stop boards from dying so quickly there. smile
One suggestion I have (untested yet) is to just stuff resistors inline with each of the I2S connections. This will limit current draw in the event of a wiring or logic mistake, hopefully preventing things from frying quite as easily. Not sure of the value to use: usually people seem to employ resistors in the 100-300ohm range for that kind of thing, but perhaps even 1-Kohm would work.

To figure it out exactly, I can look up the current draw by the WT32i for those pins, and apply Ohm's Law to that along with 3.3V, and choose a resistor value that doesn't drop the voltage below a logic "1" threshold.

Or maybe there's a better way? One could go extreme and use opto-isolators to completely protect the WT32i. Or perhaps just simple diodes to guarantee correct flow direction?

Cheers


Edited by mlord (15/12/2017 18:30)

Top
#370181 - 15/12/2017 18:32 Re: Hijack v524 is released. [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
I'm sorry to hear that things are complicated in your life. I hope that when they simplify, they do so in a positive way.

Your idea about using resistors to prevent I2S from hurting the BlueGiga module sounds useful. I'm not entirely convinced that the I2S voltage is the root cause there, but since I2S has definitely gone nonfunctional on two chips for me so far, it's certainly the right place to start looking.

Thanks so much!

Feel free to subscribe to updates at https://github.com/tfabris/BlueGigaEmpeg to get notified when I make code changes or update the bug list.
_________________________
Tony Fabris

Top
#370182 - 15/12/2017 18:38 Re: Hijack v524 is released. [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: mlord
Ah yes, we do have to stop boards from dying so quickly there. smile

Mmm.. I originally thought the WT32i was powered at 3.3V on the Betz board, but since we now know it is only 2.5V, this could be part of the problem.

3.3V is quite a bit more than 2.5V, and might need downconverting (resistor pairs again). It might even be simpler to just swap out the regulator on the Betz board for a proper 3.3V one. You could do that to repair your dead one as well. smile


Edited by mlord (15/12/2017 18:39)

Top
#370183 - 15/12/2017 18:38 Re: Hijack v524 is released. [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Originally Posted By: mlord
We should be able to just key off of the Manufacturer ID from the head-unit's MAC address, and then auto-select the appropriate security method based on that. The same type of identification could then be used for any other system-specific tweaks that might arise.


So you mean like, not necessarily figure all of the manufacturer's best schemes ourselves, but rather, default to the original scheme but add special cases to a table which changes the security scheme for each new special case we discover?

As long as it's not a catch-22 (as long as we don't need to be paired already to read the MFR ID), then that sounds do-able. I'll make a note to try that.
_________________________
Tony Fabris

Top
#370184 - 15/12/2017 19:09 Re: Hijack v524 is released. [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31563
Loc: Seattle, WA
Quote:
It might even be simpler to just swap out the regulator on the Betz board for a proper 3.3V one. You could do that to repair your dead one as well.


You mean this puppy dog, right? He's the little transistor next to the 5v pin on the Betz board right?

Willing to try it. Do you have a Digikey part number to recommend? Would the caps need to be replaced too? It would be a pain to have to replace it on every board (I have this idea of making this a kit) but if it's necessary to keep the I2S from failing then we should do it for sure.

Can you clarify your thinking as to why making the chip's voltage higher would increase its reliability? I'd think that, if the I2S lines are coming in with too much current to begin with, then increasing the overall current into the chip would just make things worse. This might be a place where I can learn more EE knowledge from you about that particular situation.



Attachments
Capture.PNG


_________________________
Tony Fabris

Top
#370187 - 15/12/2017 22:03 Re: Hijack v524 is released. [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14472
Loc: Canada
Originally Posted By: tfabris
Do you have a Digikey part number to recommend? Would the caps need to be replaced too?

Later, much, if that's okay. I'll have to look one up, and check the datasheet for the capacitors. But the onboard ones are probably just fine regardless. The tricky bit is to find an LDO (Low Drop Out) 3.3V regulator in that "package" size (SOT-23-3 ?). For sure they exist.

Quote:
if it's necessary to keep the I2S from failing then we should do it for sure.
No, we can achieve the same effect with a bunch of resistors on all of the interconnect lines. But for your semi-dead board, this would be a simpler fix. smile

Quote:
Can you clarify your thinking as to why making the chip's voltage higher would increase its reliability?

The idea is to keep the signals coming from the Arduino "in spec" for the WT32i. Referring to the "Absolute Maximum Ratings" I posted earlier, the acceptable logic levels on inputs to the WT32i must be no higher at any time than the supply voltage plus 0.3V.

So with a 2.5V supply voltage, we have to limit the serial RX and the I2S lines all to less than 2.8V. If we ran the board with a 3.3V supply, then the I2S lines would meet the spec without anything extra required.

But of course, at 3.3V, the WT32i ends up running 32% warmer than at 2.5V. Tradeoff. The resistors are probably the way to go, but wiring up so many of them starts getting messy too.

Cheers



Edited by mlord (15/12/2017 22:08)

Top
Page 10 of 18 < 1 2 ... 8 9 10 11 12 ... 17 18 >