#369609 - 20/10/2017 11:18
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
old hand
Registered: 01/10/2002
Posts: 1038
Loc: Fullerton, Calif.
|
This is something GM cars did back in the '70s and everyone copied. I dislike it as well. My cars have a vent selector and one of the choices is the defrost vents, so I can get hot air on the windshield and not run the compressor.
|
|
Top
|
|
|
|
|
#369639 - 23/10/2017 22:33
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
I think that Shonky's suggestions helped the device to have a more consistent communication with host stereo.
I now have the correct magic incantations to get the track titles sent from my code up to the host stereo. Right now they all say the same thing because I don't yet have a way to pull track titles off the empeg. But I will try to clean up my example code and provide that information to Mark.
:-)
|
|
Top
|
|
|
|
|
#369640 - 24/10/2017 00:55
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Right now they all say the same thing because I don't yet have a way to pull track titles off the empeg. But I will try to clean up my example code and provide that information to Mark. At the moment at least, that information is available to scripts/programs from /proc/empeg_notify .. if that helps(?)
|
|
Top
|
|
|
|
|
#369644 - 24/10/2017 17:58
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Thanks, Mark! I have updated my example code here: https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/previewIt contains code that successfully gets track/album titles up on the car stereo's screen using the BlueGiga WT32i development board. I still don't have anything implemented on the Empeg side to actually get those titles, but the bluetooth side of it is functional. I highly recommend getting one of those WT32i modules and using it to interface your empeg with your new car. Now that I've got most of the quirks worked out, I think this is the best bluetooth module for this task. Here's what I've learned, and it's all incorporated in to the current state of the example code linked above: - As Shonky pointed out, there are some important settings for configuring the bluetooth chip to identify itself as a certain class of device. Without that being set correctly, there will be unexpected behavior. - Once those settings are correct, then the bluetooth module will receive certain notification queries from the host stereo. Your code must correctly respond to all of those queries in turn, and if your responses are wrong, you won't get the next query in the chain. - The host stereo has to query you for the track title metadata. It comes late in the initial flurry of messages after first connection. If you don't answer all of the messages correctly then there is a chance that it might not ever get around to querying you for the track titles. - The problem where the AVRCP communications seems to "hang" for 30 seconds or more seems to be related to the class-of-device settings and the message responses. Once I got my code correctly identifying the class of device and responding to the messages, I no longer had a problem with the "hung" AVRCP messages. - There are other pieces of handshaking you have to do. Pairing with a new device can sometimes be tricky for example. I have code in there which mostly works for these purposes but I don't have a wide range of devices to test it out on. - You'll need an external way to command it to erase the bluetooth chip's paired devices and start over again. I have implemented this as a button in my prototype, but if you're doing it, it could be a hijack menu command for example. This is all in the example code linked above.
|
|
Top
|
|
|
|
|
#369645 - 24/10/2017 19:16
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Okay, great! I scored a full dev board off of eBay( *) for about USD$100 delivered to me -- about half of what it otherwise might have cost. Those certainly aren't cheap. But convenient. The raw BT module itself is a more reasonable CAD$28 at DigiKey, and wouldn't need too much glue to get going -- the datasheet shows the necessary "glue" bits.  If I get this one working, I might try a simplified design around the raw BT module later. ( *) WARNING: eBay search for DKWT32i is NSFW!! 
Edited by mlord (24/10/2017 19:44)
|
|
Top
|
|
|
|
|
#369646 - 24/10/2017 19:24
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
So.. for getting track data from the empeg:
Two scenarios:
(1) Arduino manages BT module: Hijack needs to intercept serial input, and respond to requests for track info, otherwise leaving the serial port as-was (passing everything else to the player).
(2) Empeg (Hijack) manages BT module: Hijack can safely dedicate the serial port to only the BT module; no need to worry about player commands or anything other than BT passing through.
EDIT: Or perhaps somewhat simpler for number (1): Hijack could just periodically broadcast track info over the serial port, unsolicited. The Arduino could listen for this and cache it for later response if/when queried by the head unit.
Does the Arduino sketch currently wait-for/read anything else on the serial port?
Edited by mlord (24/10/2017 19:37)
|
|
Top
|
|
|
|
|
#369647 - 24/10/2017 19:27
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
As Shonky pointed out, there are some important settings for configuring the bluetooth chip to identify itself as a certain class of device. Without that being set correctly, there will be unexpected behavior. Based on what you now know, I wonder if the issues with the earlier board might be fixable?
|
|
Top
|
|
|
|
|
#369648 - 24/10/2017 19:47
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Based on what you now know, I wonder if the issues with the earlier board might be fixable? Very astute of you to point that out. That thought had crossed my mind as well. Though none of it helps with the RN52 chip, it's potentially possible that I could go back to the BC127 chip and work from there, to see if I can solve the problems I encountered with it. However, I'm planning to move forward with the BlueGiga chip instead, for the following reasons: - The development board and the chip features seems more directly geared towards high quality audio, including the multiple RCA inputs/outputs, and specific instructions in their datasheet about ways to design the board for high quality audio. Also, if I choose to make the final module out of their dev board instead of rolling my own, most of that work is already done for me. Though the existing BlueGiga dev board is massive overkill for what I'm trying to build, at the moment I don't mind that. - The control language for the BlueGiga chip is more detailed (though harder to understand), and I feel like I have more flexibility with it. - I have already got working code with the BlueGiga chip and I would prefer to move forward rather than trying to double back to the older code at this time.
|
|
Top
|
|
|
|
|
#369661 - 26/10/2017 03:38
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 19/01/2002
Posts: 3584
Loc: Columbus, OH
|
Thanks for asking and answering that. That was my immediate thought as well when I read your update the other day.
_________________________
~ John
|
|
Top
|
|
|
|
|
#369662 - 26/10/2017 08:38
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Mark, I am responding to your earlier message in this thread that somehow I missed in the scrollback.
If you can get option 2 working (the “no Arduino at all” version) that would clearly be the best option. I just don’t have any experience coding for Linux or coding on the empeg, so I went for a system that I knew I could develop and iterate on quickly. Also, having multiple independently addressable serial ports made it easy to see everything all at once for debugging (not sure how you’d handle monitoring and debugging that if you were developing directly on the empeg with only the single serial port). But if you felt like tackling the “everything on the empeg” version, I’d offer any knowledge and help I can give.
Regarding your other question: Right now my Arduino sketch does not yet interpret strings coming in from the empeg serial port, but it certainly was my intent to make it do so, and the code is already structured in such a way that I could add it easily. It already reads and displays the text from the empeg serial port without parsing it, and it would only take a small amount of parsing code to start making use of any specially-formatted strings which appear on the empeg serial port which contain track data.
If going for the “Arduino Middleman” approach, the best option would be, as you said, to have the empeg periodically spit data out on the serial port about the current track and leave it up to the Arduino to interpret it continuously. I think the empeg already spits out regular data about the currently playing track, it just doesn’t have any track metadata in that output yet. In any case, I had planned on that scheme in my Arduino sketch: it would keep in memory the most recent information it saw from the empeg about the current track, and then when the Bluetooth module requested that information from the empeg, then my sketch would supply that information in response to the query.
If you decide to try to go the “Arduino middleman” route, i have some ideas about how the track titles should be formatted on the empeg serial port for easiest parsing.
By the way, the things that the query can respond to are already stubbed out in my Arduino sketch example code. They include the usual track title stuff, but also the current song position in MS, the total song length in MS, the current track number and the total number of tracks. It remains an open question as to what the correct answer is for the track number and total tracks. Do you give it the track’s canonical position in its album (ie the MP3’s tracknr field), or the track’s current position in the playback order (ie the playlist position or the running order position)? That’s a personal choice I guess.
Finally, I think that whatever we do, it should use the track titles as they appear in the empeg database, rather than trying to re-parse the MP3s for their tags. That would ensure all file formats work the same and ensure the titles on the car touchscreen match the empeg VFD screen.
|
|
Top
|
|
|
|
|
#369663 - 26/10/2017 17:50
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Okay. I am going for the empeg-direct-to-BT method here. But won't be doing anything for it until some time after the BT dev board arrives. An Arduino sketch is a C++ program, and I may cut and paste from yours into a native C program for the empeg. Probably just a couple of days to get it working once I begin, benefiting hugely from your efforts! In the meanwhile though, if you want track data for the Arduino sketch to parse, I can certainly provide that. Cheers
|
|
Top
|
|
|
|
|
#369664 - 26/10/2017 18:48
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Excellent!
My Arduino code isn't that great, so when you convert it, you might want to, you know, write the code better than I did. :-)
And I'd love some track data on the serial port! Ideally the output could be something like this (with an appropriate line terminator at the end of each, on the empeg that's a linefeed 0x10 right? Or is it a CRLF?):
currentTrackData_TrackName: Some Song Title
currentTrackData_Artist: Some Artist Name
currentTrackData_Album: Some Album Title
currentTrackData_Genre: Some Genre Name
currentTrackData_TrackNr: Ascii track number in decimal (probably current playlist playback position)
currentTrackData_TracksTotal: Ascii total number of tracks in decimal (probably current playlist length)
currentTrackData_TrackPos: Ascii current single track playback position in decimal, in milliseconds
currentTrackData_TrackLen: Ascii total single track playback length in decimal, in milliseconds
The exact preface strings aren't hugely important, as long as they're unique and all start with a common name so that I can detect when I need to drop into the parsing routine. The idea is: Don't surround the data with any delineating symbols like quotes or chevrons, because then we'd need to figure out a way to escape them and I don't want to deal with escaping in my parsing code. It's easier to parse on the unique phrase at the start of the line, then split them at the first colon-space, then take everything after that up to the first line terminator character.
You could spit them out on the serial port at whatever frequency you think appropriate. And I could write the parsing code so that it doesn't care which ones it gets or when it gets them, it merely interprets the ones that it sees whenever it sees them. So you could output some of them more frequently than others. For instance, only outputting the track titles and position at startup and when the tracks change, but outputting the track position and length every 500 milliseconds or so. Or output all of them every second to simplify your code, or whatever you like.
I don't know if that'd be too much data for the serial port at its default settings. I think 115200 speed shouldn't slow down the empeg too much, but I could see that, for example, if the serial port were running at 9600bps might be a bit too slow to be sending all that data all the time. My intention is to set the empeg to car_rate 115200 for this, but perhaps the serial port track data should be disabled by default in case someone's player is set to something less than that.
|
|
Top
|
|
|
|
|
#369665 - 26/10/2017 19:10
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
The usual line terminator is a LF (newline) '\n' 0x10 character. You presumably realize that you can use scanf() and sscanf() in C/C++ on the Arduino, right? Makes parsing things REALLY easy! Cheers
|
|
Top
|
|
|
|
|
#369666 - 26/10/2017 22:30
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Good point.
But strings are a bit tricky on the Arduino because the String class takes up too much memory and you're constantly having to do little workarounds that you wouldn't normally do on a full computer. The Arduino, when it runs out of memory, starts having random undefined behavior instead of showing a nice error message. I've had it happen a bunch of times already, so I'm trying to keep a rein on how much string processing I do in the Arduino code.
|
|
Top
|
|
|
|
|
#369667 - 26/10/2017 22:34
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
By the way I've updated my example code again. I found another secret incantaion in the BlueGiga module's command set that took care of an important piece of the command/response chain.
Basically, until now, the BlueGiga module would query for the track metadata just once after first connecting, and then after that, it wouldn't ever query for it again. It would keep checking playback status once per second (asking only for play/pause state and track playback position), but it wouldn't query for the changing of the track metadata.
So I found the command that I need to send to the bluetooth module which MAKES it go "hey something changed and I should query to find out what the new track looks like". The command in question was "AVRCP NFY CHANGED 1 2 1" by the way.
|
|
Top
|
|
|
|
|
#369670 - 27/10/2017 11:53
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Good. My dev board is still 2-3 weeks away from arriving here (coming from USA, so very slow). I'll grab a fresh snapshot from you when I start on it.
Yeah, String is bulky. I just use char[] arrays whenever possible.
|
|
Top
|
|
|
|
|
#369674 - 28/10/2017 09:52
Re: I made a Bluetooth interface.
[Re: mlord]
|
pooh-bah
Registered: 12/01/2002
Posts: 2009
Loc: Brisbane, Australia
|
The usual line terminator is a LF (newline) '\n' 0x10 character. LF is decimal 10 or 0x0A (hex)
_________________________
Christian
#40104192 120Gb (no longer in my E36 M3, won't fit the E46 M3)
|
|
Top
|
|
|
|
|
#369689 - 02/11/2017 18:35
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
I just noticed that there is already track data on the serial port. I didn't see it before but I'm seeing it now. I don't know why I didn't see it before. I was sure I looked for it and it wasn't there. I saw the VCB messages before but they didn't contain any track text. Now suddenly there's track text there. WTF? Anyway!!!! I just need to decipher what's there. Anyone got any tips? Is there a list somewhere of what all the messages mean?
Sending to empeg:N
serial_notify_thread.cpp: 116:@@ N1
serial_notify_thread.cpp: 117:@@ F0xbfd0
serial_notify_thread.cpp: 118:@@ TThe Camera Eye
serial_notify_thread.cpp: 119:@@ ARush
serial_notify_thread.cpp: 120:@@ GProgressive Rock
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:00
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:01
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:02
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:03
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:04
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:05
Sending to empeg: P
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:00
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:00
serial_notify_thread.cpp: 116:@@ N1
serial_notify_thread.cpp: 117:@@ F0xbfd0
serial_notify_thread.cpp: 118:@@ TThe Camera Eye
serial_notify_thread.cpp: 119:@@ ARush
serial_notify_thread.cpp: 120:@@ GProgressive Rock
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:01
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:02
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:03
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:04
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:05
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:06
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:07
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:08
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:09
Sending to empeg: W
serial_notify_thread.cpp: 170:@@ S0
serial_notify_thread.cpp: 170:@@ S0
There appear to be numeric indicators such as "180:@@" and I'm hoping each one has a defined meaning and that the numbers don't change. For instance maybe "180" is always an ASCII track playback position timestamp and 170 is always indicating that the track has been paused. Or something like that. Fun stuff!
|
|
Top
|
|
|
|
|
#369690 - 02/11/2017 18:48
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Here's what I've deciphered so far. Seems like we don't get album titles on the serial port, maybe there's something we can do about that later.
Track playback position:
180:@@ #<fid> <Track time position in ASCII H:MM:SS format>
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:00
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:01
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:02
serial_notify_thread.cpp: 180:@@ #bfd0 0:00:03
Pause/play state:
170:@@ S<1><0> (1=playing 0=paused)
serial_notify_thread.cpp: 170:@@ S1
serial_notify_thread.cpp: 170:@@ S0
Track metadata:
116:@@ N<tracknumber, actually playlist position, starts at zero>
117:@@ F<fid>
118:@@ T<track title>
119:@@ A<artist>
120:@@ G<genre>
serial_notify_thread.cpp: 116:@@ N0
serial_notify_thread.cpp: 117:@@ F0x10c90
serial_notify_thread.cpp: 118:@@ TBlue Jean
serial_notify_thread.cpp: 119:@@ AWorld Trio
serial_notify_thread.cpp: 120:@@ GJazz
serial_notify_thread.cpp: 180:@@ #10c90 0:00:00
serial_notify_thread.cpp: 170:@@ S1
serial_notify_thread.cpp: 180:@@ #10c90 0:00:01
serial_notify_thread.cpp: 180:@@ #10c90 0:00:02
serial_notify_thread.cpp: 116:@@ N1
serial_notify_thread.cpp: 117:@@ F0xe520
serial_notify_thread.cpp: 118:@@ TKeep Hope Alive
serial_notify_thread.cpp: 119:@@ AThe Crystal Method
serial_notify_thread.cpp: 120:@@ GTechno
serial_notify_thread.cpp: 180:@@ #e520 0:00:00
serial_notify_thread.cpp: 180:@@ #e520 0:00:01
serial_notify_thread.cpp: 180:@@ #e520 0:00:02
serial_notify_thread.cpp: 116:@@ N2
serial_notify_thread.cpp: 117:@@ F0x9cc0
serial_notify_thread.cpp: 118:@@ TKind and Generous
serial_notify_thread.cpp: 119:@@ ANatalie Merchant
serial_notify_thread.cpp: 120:@@ GRock
serial_notify_thread.cpp: 180:@@ #9cc0 0:00:00
serial_notify_thread.cpp: 180:@@ #9cc0 0:00:01
serial_notify_thread.cpp: 116:@@ N3
serial_notify_thread.cpp: 117:@@ F0xd780
serial_notify_thread.cpp: 118:@@ TRock Steady
serial_notify_thread.cpp: 119:@@ ASting
serial_notify_thread.cpp: 120:@@ GRock
serial_notify_thread.cpp: 180:@@ #d780 0:00:00
serial_notify_thread.cpp: 180:@@ #d780 0:00:01
serial_notify_thread.cpp: 170:@@ S0
|
|
Top
|
|
|
|
|
#369691 - 02/11/2017 19:13
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Not sure what the 136:@@ Vxx messages mean:
serial_notify_thread.cpp: 136:@@ V25
serial_notify_thread.cpp: 136:@@ V28
serial_notify_thread.cpp: 136:@@ V31
serial_notify_thread.cpp: 136:@@ V34
serial_notify_thread.cpp: 136:@@ V37
serial_notify_thread.cpp: 136:@@ V39
serial_notify_thread.cpp: 136:@@ V42
serial_notify_thread.cpp: 136:@@ V45
serial_notify_thread.cpp: 136:@@ V48
serial_notify_thread.cpp: 136:@@ V51
serial_notify_thread.cpp: 136:@@ V53
serial_notify_thread.cpp: 136:@@ V56
serial_notify_thread.cpp: 136:@@ V59
serial_notify_thread.cpp: 136:@@ V62
|
|
Top
|
|
|
|
|
#369692 - 02/11/2017 19:22
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Next question. Anyone know about this? I'm rolling my own serial interface now, using a MAX232 and some capacitors, instead of using a third party shield. I have this working so far. It works at 115200 even with only the TX, RX, and GND pins connected to the serial port. Most of the schematics I see indicate that I must also loopback some of the pins on the RS-232 serial plug back to other pins on the same plug. Some say I should loopback connect pin 7 to pin 8, and also loopback connect pin 6 to pin 4. Example: https://www.avrprogrammers.com/articles/max232-arduinoOthers say I should do the same as the above but also loopback connect pin 1 to pins 6 and 4. Example: http://justanotherlanguage.org/content/building-max232-circuit-serial-port-communicationWhat is the purpose of these connections on the RS-232 plug? And are they required for the Empeg? I'm not even sure those pins are hooked up at all on the Empeg side of things. I don't think there's enough wires on the empeg serial connector for those.
|
|
Top
|
|
|
|
|
#369693 - 02/11/2017 21:00
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Ahh, good. I was hoping I might not need to do anything special here for your setup. Hijack itself intercepts that same serial output for use in constructing the contents of /proc/empeg_notify. See this file in the empeg/Hijack kernel tree: arch/arm/special/notify.c In that small file (part of hijack), we find this:
unsigned char *notify_names[NOTIFY_MAX_LINES]
= {"FidTime", "Artist", "FID", "Genre", "MixerInput", "Track", "Sound", "Title", "Volume", "L", "Other"};
unsigned char notify_chars[NOTIFY_MAX_LINES] = "#AFGMNSTVLO";
Which is basically a guide to what you are seeing on the serial port. The notify_chars[] are the single character prefixes (Eg. 'A' for 'Artist') and the notify_names[] tells what they stand for. Got it? Also inside that source file is the hijack_serial_notify() function for parsing/collecting that information. The rest of the file deals with mostly unrelated stuff.
|
|
Top
|
|
|
|
|
#369694 - 02/11/2017 21:06
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Not sure what the 136:@@ Vxx messages mean:
serial_notify_thread.cpp: 136:@@ V25
serial_notify_thread.cpp: 136:@@ V28
serial_notify_thread.cpp: 136:@@ V31
serial_notify_thread.cpp: 136:@@ V34
...
So based on my post about notify.c, it follows that what you are seeing above is the result of adjusting playback volume. Right?
|
|
Top
|
|
|
|
|
#369695 - 02/11/2017 21:08
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
Most of the schematics I see indicate that I must also loopback some of the pins on the RS-232 serial plug back to other pins on the same plug. Those other pins mostly have to do with flow control. CTS/RTS are "hardware flow control". DTR/DSR are a way of detecting whether something is ready for more data at the other end of the cable (more flow control). DCD (aka. CD) tells whether or not the cable is plugged into a compliant device, etc. All optional, and all mostly ignored at the empeg end.
|
|
Top
|
|
|
|
|
#369696 - 02/11/2017 21:12
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
There appear to be numeric indicators such as "180:@@" I forget what the numbers are for. They seem to only increase, so a timestamp (in seconds) of some kind?
Edited by mlord (02/11/2017 21:15)
|
|
Top
|
|
|
|
|
#369697 - 02/11/2017 21:32
Re: I made a Bluetooth interface.
[Re: tfabris]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
My DKWT32i board arrived here today. Just a board. Nothing else: no docs, no dongle for reflashing firmware, or anything else. Shouldn't be an issue, but we'll see.
- Serial RX and TX in a crossover configuration to the WT32i's RX/TX pins.
- The latter will have to go through the one of those usual RS-232 chips that allows you to connect a UART to an RS-232 cable. I forget what you call that thing. In my case, I'm using an RS-232 shield for the Arduino that has that little chip in it.
So, you had to use full RS-232 levels to connect to the RX/TX pins on the header on the board? I would have guessed that the board would already be operating at 5V or 3.3V levels for those pins, but perhaps not. In other words, no MAX chip / serial converters required when connecting directly to an Arduino. What I need to find first, I guess, is hardware documentation for the dev board. Got any? EDIT: found lots on their web site, but still nothing about signal levels on that header where RX/TX are. I'll put the scope on it later to see, but probably just 3.3V for the serial port.My board works -- paired with my phone and played audio out over BT through the board to an amp/speakers.
Edited by mlord (02/11/2017 22:04)
|
|
Top
|
|
|
|
|
#369698 - 02/11/2017 22:12
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 29/08/2000
Posts: 14491
Loc: Canada
|
So, you had to use full RS-232 levels to connect to the RX/TX pins on the header on the board? I would have guessed that the board would already be operating at 5V or 3.3V levels for those pins Okay, the pins on that large header (top left on board) are supposedly direct from the WT32i module itself, so everything (digital) there is 3.3V CMOS logic. So Tony, why all of the fuss with an RS232 "shield" etc for communicating with your Arduino? It should instead just be directly wired to the RX/TX pins on the Arduino (or to any other chosen pins if using "software serial"). Oh, unless all of your RS232 stuff is for the empeg side of things. In which case it makes sense now. (?)
Edited by mlord (02/11/2017 22:14)
|
|
Top
|
|
|
|
|
#369699 - 02/11/2017 22:17
Re: I made a Bluetooth interface.
[Re: FieroSTi]
|
pooh-bah
Registered: 12/01/2002
Posts: 2009
Loc: Brisbane, Australia
|
He's talking about the empeg side, yes.
And as for looping back, ignore all that and just leave them open circuit.
_________________________
Christian
#40104192 120Gb (no longer in my E36 M3, won't fit the E46 M3)
|
|
Top
|
|
|
|
|
#369702 - 03/11/2017 04:18
Re: I made a Bluetooth interface.
[Re: mlord]
|
carpal tunnel
Registered: 20/12/1999
Posts: 31594
Loc: Seattle, WA
|
Oh, unless all of your RS232 stuff is for the empeg side of things. In which case it makes sense now. Precisely correct. The connection from the BlueGiga WT32i board to the Arduino is merely four wires: - 5v regulated power, the same power rail that is powering the Arduino (and/or the Arduino's 5v power) - Ground. - TX pin on the BlueGiga connected to RX2 pin on the Arduino. - RX pin on the BlueGiga connected to TX2 pin on the Arduino. The RS-232 shield (which I tossed out and now I'm rolling my own with a MAX232 chip and some caps) was only to connect the Arduino's RX1/TX1 output to the empeg serial port. In other words, the BlueGiga board is UART-level, not RS-232 level. It can connect to another UART but not to an actual RS-232 port without a MAX232 in between.
|
|
Top
|
|
|
|
|
|
Previous Topic
Index