Octave ORP - what's changed for 3.0.0 as my remote device code stopped working

Octave
1

Hi

I’ve just loaded the 3.0.0 new image (below) onto a mangOH yellow
yellow_wp77xx_0.6.0-octave.spk

My previously working ORP remote device microcontroller C code has stopped functioning (no response from the WP7702)

I was previously successfully using the following image.
module-2.1.3.wp77xx.spk

Has something changed in the ORP protocol or do I need to change a cloud setting ?

Thanks

John

2

Hi,
There are two important differences with ORP 3.0.0:

  1. The base path has changed from /app/remote to /app/orp/asset
  2. ORP will now send a SYNC packet on start up. This packet will be sent every 5s until a valid frame is received from the remote device

So please update your script.
The io config should be update to {“devs”: [{“type”:“serial”, “conf”:[{“baud”: “115200”, “bits”: “8”, “flow”: “N”, “own”: “orp”, “pair”: “N”, “std”: “232”,“stop”: “1”, “type”: “UART2”, “wire”: “2” } ] } ] }
“own” parameter should be updated from “remote” to “orp”

Thanks,

1 Like
3

Hi jerdung

Many thanks for the quick response. That makes sense.

Where is the SYNC packet defined?

In the existing python code a wake up sequence of ‘~’ delay100ms ‘~’ delay100ms ‘~’ was required from the external device to the WP7702 - is this still required?

A related question - I notice that for some reason the orp app (formerly known as remote) names the physical /dev/ttyHSxx as “UART2” which I guess gives a level of hardware abstraction?

Is there anyway to use ORP with serial UART ports other than the ones built into the WP7702?
For example I’m thinking of using a USB serial device on the IoT expansion connector (ttyUSB0<->HSIC <-> USB HOST <-> Physical UART).

Thanks in advance

John

4

Hi johnofleek,

SYNC: Unsolicited notification sent from the ORP service to the remote to indicate that the service has restarted.
After a restart of the ORP Service, the service will periodically send this message until either a direct response is received from the remote OR the remote sends any other valid packet. Once a response has been received, the ORP service will update its status to “connected”

Notification: <packet type[1]><version[1]><sequence[2]>
packet type: ‘Y’
version: Maximum ORP version supported
sequence: unused
timestamp: ‘T’
received: ‘R’. Packets received since restart, equal to zero (ASCII decimal, NOT null terminated)
sent: ‘S’. Packets sent since restart, equal to zero (ASCII decimal, NOT null terminated)

example: you will see these messages every 5s until you sent a valid frame to device
Received : Y101T315968599.000000,S0,R0
Status : TIMEOUT
Timestamp : 315968599.000000

Received : Y101T315968604.000000,S0,R0
Status : TIMEOUT
Timestamp : 315968604.000000

Received : Y101T315968609.000000,S0,R0
Status : TIMEOUT
Timestamp : 315968609.000000

The delay time is not necessary after restart ORP service, you can handle by capturing the SYNC message.

And, the UART in the io config is the UART of WP77 chipset, there are 2 UARTs for WP77. On MangOH Red/yellow, UART1 is mapped to IoT expansion connector, and UART2 is mapped to Console USB port.
You can use these UARTs for ORP service.
The details for CF3 pin is in this document https://mangoh.io/uploaded-documents/Reference/mangOH%20Yellow/Discover/Hardware%20User%20Guide/mangOH_Yellow_User_Guide.pdf

Thanks,

1 Like
5

Hi John,

Just to expand on the reply from jerdung:

Regarding your question about the sending of tilde characters (’~’) in the python script:

The UARTs of the WP77 will enter a low power mode after a period of inactivity - this period is on the order of seconds. While in this mode, the UART’s sampling clock is disabled. The clock is reenabled when activity is seen on the RXD line. Particularly at higher data rates, the first few bytes inbound on RXD may be missed due to delays in restarting the clock.

To avoid missing important bytes, a preamble is used to ensure that at least one Start-Of-Frame byte is recognized. The tilde (’~’) is of course the same as the SOF byte. This could just have easily been written as a longer sequence of SOF bytes with no delay.

So, yes. This preamble is still required.
.
.
About the device names; “UART2” as opposed to /dev/ttyHSxx:

Yes, this is to provide a level of abstraction for the user. On the FX30 platforms, the tty actually differs depending on the mode in which the UART is operating (RS232 or RS485). UARTx is also the familiar name from our PTS.
.
.
For using ORP with other serial devices (tty): We don’t currently support this but you may want to raise it with your FAE.

Thanks,
Ian

1 Like
6

Hi Ian and jerdung

Thank you both for the information.

Regarding the Octave ORP preamble requirement to wakeup the Octave Edge device UART.

  • What is the minimum wakeup requirement ? maybe this is an amount of time as opposed to a number of characters?
  • I guess the minimum wakeup requirement is dependant on external implementation factors such as the RS485 / RS232 hardware and the actual processor platform in use - so maybe some sort of validated against product table?

Also thanks for the update on the SYNC packet. The SYNC packet isn’t currently documented in the Octave documentation. It would be useful to see this added.

ORP will change over time as the protocol evolves - so maybe some notes in the documentation on the protocol versions as well?

Thanks in advance

John

I’ve created a separate thread covering WP7702 UART wakeup here