Serial synchronous communication

Projects General Guidance
1

Hello,

On a current project, I'm trying to understand how the communication between an old 80's Japanese sampler and its remote works.
From the service manual of the machine, I can gather the following informations :

serial_sync
serial_sync2012×1472 263 KB

  • Communication is serial & synchronous
  • To send data to the sampler, 3 Pins should be used :
  1. DATA1 (input) : actual data/command to send
  2. ATN (input) : Ready signal input (HIGH when no activity, LOW when there's some message to send
  3. CLK1 (output) : Clock signal

I've started looking for ways to send serial data synchronously (SPI, I2C), but none of them seem to fit or work so far. What would be the best approach to try to send serial data synchronously from the Arduino ?

Thanks !

The sampler : https://www.synthxl.com/wp-content/uploads/2019/05/Roland-s-330-service-notes.pdf
The remote : https://www.synthxl.com/wp-content/uploads/2019/05/Roland-rc-100-service-notes.pdf

2

The data sheet shows the sockets on the back and what they do .
I can’t see a coms socket - what are you hoping to achieve ?

3

I will take a SWAG and say the clock is 16x the data rate. If so that was designed for a USART chip, used a lot before they became incorporated in processors. The μPD8251A/AF was popular years ago and used for both synchronous and asynchronous communications. Note these devices output/receive a digital signal, there needs to be a driver/receiver between them and the bus.

4

On the front panel of the sampler, you have a DB9 socket where you can plug the remote (RC100) to control the sampler parameters and menu browsing.
My objective would be to control this from the Arduino.

db9

5

You can do this with a variant of ‘software’ SPI.
Set up your shift routine to handle the shifting and clock to match the format you need.

6

First determine if the data and protocol is ASCII or EBCDIC.

7

From the 80's, each bit is sent on the rising edge of the clock signal. Receiving, each bit is determined by the clock at mid bit time.

8

Apologies - didn’t spot that !

1 Like
9

Are the data/command protocols proprietary? You would need that as well to use it.

10

Yes, protocol is proprietary, but I got some info about it. So the commands themself should not be a problem.

11

So, what clock rate are you going to use?

12

The table quoted in the OP says that the clocks are outputs... I think,

13

Would be nice to anticipate what the frequency might be, since he will have to wright the code the use it. Do we know if the clock is TTL or some odd voltage?

14

Since the Clock seems to be generated by the sampler, i'm not sure I need any clock rate detail.
I'm also assuming that the clock is using TTL voltage.

I'm waiting for a delivery on a "real" oscilloscope next week to start debug all of this.
(until now, I am using a 20 $ Chinese DSO kit as an oscillo, which was ok for small diy projects, but is a bit of a pain to debug multiple signal at once :slight_smile: )

15

Good. You will need to see if the clock signals are identical of if one is offset from the other.

16

Do not assume, measure!

1 Like
17

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.