What's new
I'm not up to speed on the absolute latest in versions of the Pi, but I tend to always buy Pi 3's since the price difference isn't that big. Any reason not to just default to the highest performer?
 
Project Update:

Unfortunately a negative update this time, I tried running it on a Raspberry Pi 1st gen today for the first time (had been developing on my mac, but target platform was obviously a Pi) and annoyingly it just doesn't work.

I'm thinking that the PI can't process + reply fast enough and so its a speed issue. I will try on a better Pi2 or Pi3 later to see if that helps, or failing that attempt to make the code and linux distro more efficient.

So if anyone tries this on a Pi1 and it doesn't work, thats to be expected for now!
uhmm... what doesn't work? the jvs protocol handler?
iirc, pi has somekind of serial debug port, which is useful for debugging.
 
@winteriscoming Only reason for using the Pi1 is because I have lots of them at home - but i've got a pi2 that i'll test it out on.

@Dion Yeah its my code that doesn't work, on a raspberry pi for some reason. Thats cool - luckily I should be able to just debug by printing to the standard console, and seeing what the PI is outputting etc.

Small Update:

I've decided to re-write the project in C, and now that i've done that its blazingly fast! I actually had to put lots of sleeps in the code as it was running too fast for the Naomi to keep up. This also means that once all the code is properly down, it will be easy to port to Arduino/Pics etc if it gets to that point.

Interestingly however, it still doesn't run on a Raspberry Pi 1 with Raspian, so i'm thinking its probably not the speed issue and something else to do with how it handles serial.

On holiday for a bit now, but should have a Raspberry Pi .img soon for testers once i've figured out the issue.

Another Update:

Just tried it out on a Raspberry Pi 2 and the same issues, it looks like its running but the Naomi never reads the replies and keep asking for the same thing over and over again.

Unsure why this works fine on my Mac on both the Python and C version, but fails on a Pi1/2? If there is anyone that knows about C/Linux/Raspberry Pi's that could help, please PM me!
 
Last edited:
How are you interfacing the pi to your rs422 interface?
 
@rtw I have a USB to RS485 converter that shows up in unix as a '/dev/ttyUSB0' device on either my Mac or Raspberry Pi. I then simply read and write to it like its a file from C. I've set all the permissions of the /dev/ttyUSB0 device to 777, so I don't think its a permissions problem, and i've been running the program as root anyway so a bit stumped. The only things I can think are the timings are different for some reason?
 
RS485 is a half duplex protocol. You basically take the bus by enabling the transmitter and you need to turn the transmitter off to free the bus so that another device can answer. The problem with usb 2 serial adapters is that the serial data is usually send in bursts of multiple bytes. This makes it extremely difficult to disable the transmitter directly after the last byte was sent out. (The serial transceiver chip has a fifo buffer). Ftdi has an usb to rs485 adapter on to which the chip itself controls enabling and disabling the transmitter. I noticed that your usb to rs485 uses a cp2102 chip. Not sure if it works equal. Ftdi dongles are expensive (compared to other brands). You can buy a teensy or an arduino for the price of the ftdi dongle. That approach is more flexible than the dedicated dongle one, but it involves some programming.
Some approaches use one of the serial control lines like RTS to enable the rs485 transmitter. The timing accuracy that can be obtained with such approach is terrible with an usb 2 serial dongle.
If you have 2 of such dongles, you can check if the transmitted data is arriving correctly on the bus. Also note that often the bus D+ and D- lines are connected to 5V and GND with a 1K resistor. This prevents garbage on the bus when no transmitter is active.
 
  • Like
Reactions: rtw
We had an rs485 adapter that used the pi serial pins. That one used the pi txd signal to drive the transmitter enable as well. So basically, only the 1 or 0 bit's where actually sent out by the rs485 chip. For the other bit's, it relied on the pull up and pull down resistor to keep the RS485 lines in the correct status. Such an approach works for short distances but isn't the correct way to do things.
Further on, the pi serial port is normally used as tty console in linux.
Even some of the early bootloader files use that port to output status information and need recompilation with that output disabled to avoid garbage on the serial port during startup.
Another approach that exists is triggering a timer with the txd signal that keeps the transmitter enabled for at least the period of one byte. Problem is that the timeout changes with the used baudrate. If the timeout is 2 long, you risk to loose part of the response from the other device on the bus.
On pi 3b, they use the good uart for bluetooth. The other uart can have drift on it's clock signal resulting in communication errors. So, I wouldn't recommend to use the pi gpio uart lines, unless you are willing to investigate a lot of time to get it going properly.
 
Update: On a re-read of obcd's post, I now understand what your saying. Possibly the Raspberry Pi's serial driver, isn't sending the 'im finished' signal properly and so the device has the TX enable pin still high so the Naomi can't send to it. I'll have a look at adding flushes etc. to see if that works! Thanks!

Thanks both for the reply, interesting read although I didn't fully understand all of it! However I don't want to use the RS232 pins on the Pi, mainly because its more wiring than I want to do + the usb converter works on a PC and so there should be no reason why it can't work successfully on a Pi as well.

My thinking though is that I can get the JVSEmulator to run perfectly on Mac OS on a Mac and on Ubuntu and Windows on a PC, and so its either something specifically to do with the Pi's hardware that is making it work incorrectly, or the Raspian distro having some dodgy driver for the device, or handling serial in a strange way, or its something to do with timing, but i'd be suprised if the timing of the program was moved so significantly by the Pi.

My plan is as follows:

- Run Debian/Raspian on my laptop to see if I get the same effect as on the raspberry pi there
- Run Arch on a raspberry pi to see if it works correctly with a different distro
- Possibly purchase a different brand USB to RS485 converter and see if that works.

Thanks @rtw and @obcd for your help!
 
Thanks for everyones help on this - turns out that it works fine using Ubuntu on a raspberry pi so it must be some problem with the Debian distribution.

Should have a working .img for the raspberry pi soon, and should hopefully work on all versions.
 
Thought i'd put an update seeing as @winteriscoming mentioned this in his post, where he open sources his Mega JVS project.

The current status is that there is a C version and a Python version of the project, both in various states of working - but no simple plug and play solution for people with limited pc know how yet.

The python version will work fine on a fairly powerful computer, but not a raspberry pi. The C version seems to work on some machines but not others, and i'm assuming this is to do with the different drivers for the USB to RS485 converter. There are various modules available that allow you to use the mouse, or some keys on the keyboard and someone with some python know how would easily be able to add their own joystick steering wheel.

I've put the project on hold for a while, as I've found it very hard to get it running reliably on a Raspberry Pi (I believe due to the way the operating system, and hardware handles the USB to RS485 device). Going on holiday soon, and starting a new job - so hopefully after thats settled i'll be ready with a fresh mind to work on it again. If anybody would like to work on it with me, or solve my problem please send me a personal message, and i'd be more than happy to work with you.

Instructions on making your own device are here:https://github.com/bobbydilley/JVSEmulator/wiki/The-JVSE-Cable

The code is available here: https://github.com/bobbydilley/JVSEmulator

Please be assured that i've not given up on the project, and that I apologise for it being slow off the ground. Once the timing bugs are sorted, it will be only a matter of time before lots of different joysticks and devices are sorted and hopefully we can come up with some sort of spec like winteriscoming's profiles for his MegaJVS, that allow all our custom JVS devices to share config files etc.
 
@bobbydilley Awesome, thanks for sharing. I was recently building something very similar with Node, but had problems with the timings and/or making the sense line work. I'll have a look at what you've done, because it seems you got it generally working and it's all about polishing/completing it from there.

I'm moving houses next week, but really keen to give things a go again.
 
@mtn Would be great if you could take a look, when your ready send me a message and I can talk you through what I’ve done! With the sense line I simply connected it to ground and it just works - as long as you don’t want multIple daisy chained IOs it’s easier to do this and not have to worry about driving the sense line at all! Good luck with the house move!
 
If I understand no need JVS I/O board...so nice maybe it could be adapt for xbox and chihiro game...except ghost squad and VC3 all game crash after JVS check.... thx for sharing C code. I try to read it.
 
Last edited:
Hi there,

The code unfortunately would likely not be of use on an Xbox, as it doesn’t have the right hardware to talk JVS over RS485. I suspect that the JVS gets converted to Xbox signals before it hits the game board.

It should work with a Chihiro absolutely fine though!
 
It could be help for understand and maybe make something, 2 ways like you external hardware connect by controller port (it's an usb 1.1) or software...but this make some of probleme we cant launch some of executable in same time and RAM limitation too....
 
Little update:

I’ve tracked down the error on the Raspberry Pi - but it’s a wierd one.

The JVS protocol works like this:
1. The Naomi sends a sync byte
2. The Naomi sends the address of the device it wants to talk to as a byte
3. The Naomi sends the length of the data it’s about to send as a byte
4. The Naomi sends length amount of data bytes.

This all works on a Mac, and all works on a raspberry pi except for step 3 when in a game. In the test menus it works fine, but in the game it gets the length of 9 and not the correct length of 12. The data bytes after the length is sent are also correct.

So very stumped as to why it manages to get the length wrong, but everything else correct! Tonight I’m going to try adding a resistor inbeteeen the data lines to see if that helps.

Was wondering if anyone had any ideas on what might be going on?

Thanks,

Bobby

Code is here: http://github.com/bobbydilley/OpenJVS
 
Little update:

I’ve tracked down the error on the Raspberry Pi - but it’s a wierd one.

The JVS protocol works like this:
1. The Naomi sends a sync byte
2. The Naomi sends the address of the device it wants to talk to as a byte
3. The Naomi sends the length of the data it’s about to send as a byte
4. The Naomi sends length amount of data bytes.

This all works on a Mac, and all works on a raspberry pi except for step 3 when in a game. In the test menus it works fine, but in the game it gets the length of 9 and not the correct length of 12. The data bytes after the length is sent are also correct.

So very stumped as to why it manages to get the length wrong, but everything else correct! Tonight I’m going to try adding a resistor inbeteeen the data lines to see if that helps.

Was wondering if anyone had any ideas on what might be going on?
when you said getting wrong length, could you give more details? in raw hexs. and what the game title and in which platform?
 
@Dion Thanks for offering your help - I’ll send that all over when I’m home from work!
 
Back
Top