Arduino Uno:
If I send serial data into the USB jack, where can I pick-up the data; on pin 0 and 1?
Yes, serial data will be present on the pins marked TX->1 and RX<-0. bear in mind that for viewing data you have Serial Monitor and if you want to connect something there, then it may interfere with sketch uploads.
Thank you so much. I will give it a try.
I had the interference problem with connections to the Tx and Rx pins. I solved it with a 74HC126 quad tri-state buffer. Works a treat.
AJLElectronics:
I had the interference problem with connections to the Tx and Rx pins. I solved it with a 74HC126 quad tri-state buffer. Works a treat.
Please post your circuit diagram.
...R
Thank you very much for that. Do you need special Arduino code to make it work?
It seems extremely complicated - IMHO well beyond the capabilities of a newbie. What was the purpose of it?
If you need to have multiple TX connections to a single RX pin you can achieve that with a pullup resistor to hold the RX HIGH and a diode to isolate each Tx.
...R
No special code at all. The buffers go high impedance when the 12V supply disappears.
The device is one that I have been trying to buy for a long time without success. I had been talking to a large manufacturer who were going to develop it "on the side" but the lockdown knocked that on the head.
The purpose?
I have a BMW K1200LT motorcycle with factory fitted Professional 2000 radio and seperate controls. Over time, I had hung various adapters on it for streaming radio, hands free etc but it was all a bit messy and Heath Robinson. The issue is that if you take the original radio out, the control panel and switches all go dead. This device is an interface to allow the Ibus data from the factory radio to be emulated and used to control an Alpine head unit via IR. It is still being developed, just tonight I have managed to write to the original factory display and track the source button, with no connection of any sort between them!
The beauty of it is the customisation possibilities. It is dead easy to map the original controls to give the functions preferred, as well as operating the optional switch outputs.
As far as complicated goes, it's really not. My circuit diagram was run up quickly and so doesn't read so well.
The Ibus is connected to a Bus tranceiver. In the circuit diagram, it is the Melexis TH3122, although in my MkIII prototype in the photo, I have use an MCP2025-500.
The Bus tranceiver is connected through a pair of buffers to the Nano and Vicky Verky (nice girl!).
The LM78L05 merely provides a 5V logical high to the buffers when the ignition is in the RUN or ACC positions. To upload a modified program, all that is necessary is to turn off the ignition and the buffers float.
The two transistors are there to provide switching outputs for whatever. I use one for my PTT and the other is currently unused. The 5V output on the connector has no real use, so may add another switch. Then I can do PTT as well as channel up and down, if I ever get around to connecting it all up!
AJLElectronics:
The purpose?I have a BMW K1200LT motorcycle with factory fitted ....
That is a very specific requirement. I doubt very much that it has any relevance to the OP's question. IMHO putting this in this Thread is just unhelpful for the OP.
By all means make a write-up of your own project in the Exhibition / Gallery section for the benefit of Forum members who may be faced with a similar problem to yours.
...R
I beg your pardon Robin, the point came up about the communication pins being affected by added connections which I offered a solution for. You asked what is was and I gave the courtesy of an explanation.
To condense it, a single tri-state buffer in each of the Tx and Rx lines is all that is needed to do the job. The enable can be fed with a transistor to invert from the USB socket, meaning the the lines disconnect when the power from USB is sensed. Otherwise a tri-state buffer is available that is reverse logic and wouldn't need the transistor. That is very simple, I am not sure why you consider it otherwise? In my opinion, it is condecending to assume it is too complex a notion for "newbies", especially when I am happy to offer further help.
AJLElectronics:
You asked what is was and I gave the courtesy of an explanation.
To be honest, the reason I asked was because I suspected it would be a too complex solution for the OPs question.
I am not criticising the quality or utility of your project for people who have a similar requirement to yours.
However I feel strongly that advice that is offered on this Forum should be appropriate to the level of knowledge and experience of the person asking the question.
...R
I hear what you are saying Robin, but who are we to make instant assumptions about the calibre of those asking programming advice? I confess to not having anything like your knowledge of programming, but I do have plenty of electronics experience. I could make an instant assumption that it is actually you who doesn't understand, which would be just as unfair.
I am currently working on the 'bike, so time is short right now. What I will do later is to simplify it and show an example of using the buffers that will be as easy to understand as relays.
Friends now? 
AJLElectronics:
I hear what you are saying Robin, but who are we to make instant assumptions about the calibre of those asking programming advice? I confess to not having anything like your knowledge of programming, but I do have plenty of electronics experience.
I suspect one my strengths is that I don't have a huge knowledge of programming and perhaps that helps me to view things from the point of view of the inexperienced newbie.
And, in my experience, the style of the question (this case is a great example) provides a big insight into the level of knowledge of the person asking the question.
IMHO it is wiser to assume little experience rather than a lot of experience. Posting a reply aimed at an experienced user can discourage a newbie from pursuing the matter further because they think it is just too complicated.
On the other hand it is easy for an experienced user to say "I know all that, what I'm having trouble with is ..." From which one might infer that the experienced user ought to have used their experience to write a better question 
...R
As promised, a very basic guide to the 74HC125 and 126.
A 74HC125/6 is a very useful device. Its manufacturer's description is a "Quad Tri-State, non-inverting buffer". Now that is a bit of a mouthful and perhaps meaningless to those of us new to such things.
Like anything that appears complex, break it down into smaller parts and it becomes easier to understand. Taken one word at a time, the Quad just means that there are four identical buffers on the device. You can use just one, two, three or them all. If not using them all, it is is a good idea to connect the unused inputs to 5V or ground. You can see that in my circuit a few posts back that I have put them in series, even though two of them appear to be doing nothing. The reason I did that was that it was just as easy to wire them like that and it meant that the physical connections on the IC became much more convenient for my board layout. I could have left them out otherwise.
Note also in that circuit that the symbol is incorrect. It was a quick drawing and it was the only one available in the limited library I was using.
Tri-State is an interesting one... most digital devices like the Arduino work on two logical states, either logical high or logical low. Both can be read or set as required. With a Tri-State device, we have one further state know as "high impedance". In simple terms all that it means is that it 'switches out of circuit' when told to and behaves just as if it has been unplugged.
Non-inverting, means that whatever the input is, the output will faithfully follow it, so high in equals high out and low in gives low out. The logic of the input signal is not changed in any way.
A buffer (generic) is useful for many things. It can protect one part of a circuit from another, clean up noisy signals, change impedances to match devices as well as increasing drive current etc. The simple transistor that is used to drive a relay from the Arduino is an example of one type of buffer.
Knowing all this means that it can be put to work for us in many ways... Probably the most basic use is to treat it as a solid state relay. It has an input, an output and a pin to make it operate when it gets 5V or 0V according to the type selected. This is known as "active high" and "active low" The 74HC125 is an active high device, which means that it will go high impedance (disconnect) with 5V on its Enable pin. If you want the opposite function, ie active low, choose the 74HC126 instead. It is otherwise identical. Datasheets are freely available on both devices.
Here are a few scribblings to try to illustrate how they can be used...
Putting a buffer in series with the Arduino's serial lines means that we can overcome the problem of not being able to upload new sketches when something else is connected to them. One buffer in the Tx line, one in the Rx line and the enables taken to the USB socket power pin.
Now whilst the Arduino is running from an external 5V supply as it should be, the buffer's enable inputs are low. Therefore all signals pass as normal. When USB power is applied, the buffers Enable pins go high and so disconnect the serial lines completely.
The bottom circuit is just an example of another use for the buffers. Setting the relevant Enable pin high will disconnect that buffer, whilst allowing the others to pass normally.
A side note about serial devices from bitter experience...
One of the issues that can arise with some projects is what happens when you connect the standard serial port's Tx and Rx lines to another serial device. There is a convention that the transmit has to be connected to receive on the other device and that is always true and makes perfect sense.
What sometimes muddies the water is when the manufacturer of a serial device decides to describe the pins of their device with reference to the outside world. So for example, a signal arriving from outside the device such as a databus, is of course being received by it. It would be logical to expect that to appear on its transmit pin because it is going to be received by the microprocessor on its Rx pin. Not so, leading to the apparently incorrect connections of Tx to Tx and Rx to Rx!