How to debug "[BaosSerial] Timeout"

[sichiwai]

Hi,
I am trying to get my kBerry to work.
While I was (partially) successfull using knxd to program it, I still fail on many operations, such as using the sample_BaosSerial.

The output of sample_BaosSerial:
./sample_BaosSerial
12:21:56:628 [] Console Logger Started
12:22:01:686 [BaosSerial] Timeout

How can I debug this?
I followed the instructions on https://github.com/weinzierl-engineering/baos/blob/master/docs/Raspbian.adoc .

Any help would be appreciated
------------------------------------- additional information -------------------------------
uname -a:
"Linux openHABianDevice 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux"

tail /boot/config.txt:
[all]
gpu_mem=16
enable_uart=1
dtoverlay=disable-bt

[sichiwai]

With the logger set to 8, I oberserve the following output: ./baos_connect /dev/serial0 15:30:23:771 [] Console Logger Started 15:30:23:774 [kdrive.io.serial.SerialPort] Opening serial port /dev/ttyAMA0, speed 19200, parameters 8E1, flow control none 15:30:23:775 [kdrive.io.serial.SerialPort] Sending 4 byte(s) 0000 10 40 40 16 .@@. 15:30:23:775 [kdrive.ft12.FT12_Packetizer] ft1.2 tx: 10 40 40 16 15:30:23:780 [kdrive.io.serial.SerialPort] Received 1 byte(s) 0000 E5 . 15:30:23:780 [kdrive.ft12.FT12_Packetizer] ft1.2 rx: E5 15:30:23:781 [kdrive.io.serial.SerialPort] Sending 8 byte(s) 0000 68 02 02 68 73 A7 1A 16 h..hs... 15:30:23:782 [kdrive.ft12.FT12_Packetizer] ft1.2 tx: 68 02 02 68 73 A7 1A 16 15:30:23:789 [kdrive.io.serial.SerialPort] Received 1 byte(s) 0000 E5 . 15:30:23:789 [kdrive.ft12.FT12_Packetizer] ft1.2 rx: E5 15:30:23:799 [kdrive.io.serial.SerialPort] Received 8 byte(s) 0000 68 0C 0C 68 F3 A8 11 21 h..h...! 15:30:23:803 [kdrive.io.serial.SerialPort] Received 8 byte(s) 0000 00 C5 01 02 DC 94 00 04 ........ 15:30:23:806 [kdrive.io.serial.SerialPort] Received 2 byte(s) 0000 09 16 .. 15:30:23:807 [kdrive.io.serial.SerialPort] Sending 1 byte(s) 0000 E5 . 15:30:23:807 [kdrive.ft12.FT12_Packetizer] ft1.2 tx: E5 15:30:23:807 [kdrive.ft12.FT12_Packetizer] ft1.2 rx: 68 0C 0C 68 F3 A8 11 21 00 C5 01 02 DC 94 00 04 09 16 Checking connector for operation connection established 15:30:23:809 [kdrive.io.serial.SerialPort] Sending 13 byte(s) 0000 68 07 07 68 53 F0 01 00 08 00 01 4D 16 h..hS......M. 15:30:23:810 [kdrive.ft12.FT12_Packetizer] ft1.2 tx: 68 07 07 68 53 F0 01 00 08 00 01 4D 16 15:30:23:819 [kdrive.io.serial.SerialPort] Received 1 byte(s) 0000 E5 . 15:30:23:820 [kdrive.ft12.FT12_Packetizer] ft1.2 rx: E5 15:30:28:828 [kdrive.io.serial.SerialPort] Closing serial port 15:30:28:829 [BaosSerial] Timeout

[KHBuchner]

This does not look too bad, it shows that both directions are working:
68 02 02 68 73 A7 1A 16 from 15:30:23:782 is EMIC_PEI_IDENTIFY_REQ from raspberry, which is answered by kberry with 68 0C 0C 68 F3 A8 11 21 00 C5 01 02 DC 94 00 04 09 16 (EMIC_PEI_IDENTIFY_CON). Please have a look at https://www.weinzierl.de/images/download/development/830/KnxBAOS_Protocol_v2.pdf for more information about FT1.2 protocol in chapter 4.1.
68 07 07 68 53 F0 01 00 08 00 01 4D 16 from 15:30:23:810 is a GetServerItem.Req to serial number of kberry, but there seems to be no answer. Is this a fresh install of raspbian?

[sichiwai]

Hi, the system is as "new" as an openhabian with knxd gets. I tried a few things, but in essence the sequence is the same for knxd (which was disabled and killed for the test of baos). Cheers Sent from MailDroid

…

-----Original Message----- From: KHBuchner <notifications@github.com> To: weinzierl-engineering/baos <baos@noreply.github.com> Cc: sichiwai <christian.iwainsky@web.de>, Author <author@noreply.github.com> Sent: Fr., 13 Nov. 2020 8:44 Subject: Re: [weinzierl-engineering/baos] How to debug "[BaosSerial] Timeout" (#14) This does not look too bad, it shows that both directions are working: 68 02 02 68 73 A7 1A 16 from 15:30:23:782 is EMIC_PEI_IDENTIFY_REQ from raspberry, which is answered by kberry with 68 0C 0C 68 F3 A8 11 21 00 C5 01 02 DC 94 00 04 09 16 (EMIC_PEI_IDENTIFY_CON). Please have a look at https://www.weinzierl.de/images/download/development/830/KnxBAOS_Protocol_v2.pdf for more information about FT1.2 protocol in chapter 4.1. 68 07 07 68 53 F0 01 00 08 00 01 4D 16 from 15:30:23:810 is a GetServerItem.Req to serial number of kberry, but there seems to be no answer. Is this a fresh install of raspbian?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #14 (comment)

[KHBuchner]

I don't know openhabian and knxd, but could it be that it changes the configuration of kberry, e.g. set it to link layer? For more information about link layer please have look at https://www.weinzierl.de/images/download/development/830/KnxBAOS_Users_Guide.pdf e.g in chapter 5.2

[sichiwai]

FYI:
openhabian is a variant of raspberrian tailored for homte-automation (https://www.openhab.org/)
knxd is a community implementation of a knx server & interface (https://github.com/knxd/knxd). I initially tried to use the kBerry with KNXD for tunneling to the bus - which to some degree worked, but had some issues.
Then I tried to see, if the baos Demo would worked without issues.
This brought me here.

Is there some way to "reset" the kBerry?

At this point, I am setting up a vanilla raspberry pi system and retest.

[sichiwai]

OK, in the documentation (baos users gude, page 81) was the description on how to reset. Which I did. And now the example works.

Question: is it possible to use the kBerry both in BAOS and in link layer mode?

[KHBuchner]

No, unfortunately, this is not possible

[sichiwai]

ok, unfortunate.
Just to understand this completely: So if I use the BAOS to store some values, then switch to link layer mode. Will those values still be accessible? Or does the link layer mode deactivate the "BAOS" functionality?

[sichiwai]

Remark: When using KNXD it leaves the kBarry in link layer mode, regardless of what it was doing before hand.
Hence, I would suggest adding a mechanism to the serial example, that explicitly switches the kBerry to BAOS mode.

[KHBuchner]

We will diskuss this for future versions of BAOS library. Switching mode causes new initializing of the respective mode. so all previous data is lost.