CC1101 transceiver from pollin and connections

English Forums Hardware
#1

Hi all,

I just registered and this is my first message! Thanks for what you are doing in this area.

I have to learn a lot and I bought a set of three MAX! devices and the adapter from pollin listed on the wiki (on the page homegear.eu/index.php/Hardw … quirements , in the section about MAX! devices), as well as a banana pi, so I should be all set :smiley:

From what I have seen on the wiki, there is a connection-scheme which refers to another adapter (the one from aliexpress, I guess). I would like to know whether there is something similare related to the adapter I bought.

Kind regards,
Daniele

#2

Hey Daniele,

here is what you need to connect:

Modul       RPI
VCC         3.3V
GND         GND
MISO        MISO
MOSI        MOSI
SCK         SCK
CS          CE0
GDO0        GPIO25 (or any other free GPIO)

Then add the following to your physicalinterfaces.conf:

[MAX]
deviceType = cc1100
device = /dev/spidev0.0
responseDelay = 45
# "0" if GDO0 is connected to GPIO of Rasberry Pi or "2" if GDO2 is connected
# You only need one GDO (0 or 2), it doesn't matter which one you use.
interruptPin = 0
# GPIO pin on Raspberry Pi the GDO of the module is connected to.
gpio1 = 25

Cheers,

Sathya

[1] https://forum.homegear.eu/viewtopic.php?f=6&t=10#p130

#3

Hi sathya! Thanks a lot for your help.

Now I’m on vacation and I can work on my project! :slight_smile:

I did read the thread you posted, but unfortunately my situation is a bit different: On the SBC side I have a Banana PI instead of a Raspberry PI, and on the module side I have a different module (at least the pinout is different).

I am attaching the schematics I reconstructed using your post as input, the datasheet of the module [1] and the description of the banana PI [2].

connections.png1088×546 105 KB

Can you please let me know if you see major faults with my schema? I don’t want to “fry” anything :slight_smile:

Best Regards,
Daniele

[1] pollin.de/shop/downloads/D810257D.ZIP
[2] bananapi.org/p/product.html

#4

Hey Daniele,

looks good :wink:.

Cheers,

Sathya

#5

Thanks Sathya, off to the soldering station, then! :smiley:

I’ll keep you posted!

Daniele

#6

Update: the adapter is connected and it seems to be recognized by the system:

[ 1217.466817] [spi-inf] Found 2 spi devices in config files
[ 1217.479208] [spi-inf] boards num modalias         max_spd_hz       bus_num  cs   mode
[ 1217.491022] [spi-inf] spi_board0 irq gpio not used
[ 1217.502931] [spi-inf] 0          spidev           12000000         0        0    0x3   
[ 1217.514914] [spi-inf] spi_board1 irq gpio not used
[ 1217.526805] [spi-inf] 1          spidev           12000000         0        1    0x3   
[ 1217.539956] [spi-inf] sun7i_spi_probe: spi0 dma type: normal
[ 1217.549498] [spi-inf] bus num = 0, spi used = 3 
[ 1217.558732] [spi-inf] sun7i_spi_probe: spi0 cs bitmap: 0x3
[ 1217.573184] [spi-inf] sun7i_spi_set_mclk: spi0 source = sdram_pll_p, src_clk = 432000000, mclk 86400000
[ 1217.588822] sun7i-spi sun7i-spi.0: master is unqueued, this is deprecated
[ 1217.604779] [spi-inf] sun7i_spi_probe: reuuimlla's SoC SPI Driver loaded for Bus SPI0 with 2 Slaves at most
[ 1217.624328] [spi-inf] sun7i_spi_probe: spi0 driver probe succeed, base f01b8000, irq 42, dma_id_rx 24, dma_id_tx 24

But I had to manually load the module before. I am now installing homegear :slight_smile:

Edit: it seems to work: I have seen the following in the log:

12/27/14 16:49:43.319 MAX packet received (cc1100, RSSI: 0x54): 8BC5D44148212[lots of other hex digits that I omit because I fear they may contain sensitive information]

My problem now is that payring does not work and I don’t know why. But I’ll create a thread in the right board.

Thanks!
Daniele

#7

Ok, I’ll keep posting in this thread because I am not sure wether I have an hardware problem or not.

After connecting the transceiver and installing homegear I’ve seen some packets in the log and was very happy, but from what I’ve seen the pairing packets should not start with 8X (I’ve seen 84,85, 8D).

If I choose a higher debug level I see a lot of CRC errors (many of them each second) and when I try to pair the valves I see a message about a MAX! packet longer than 200 bytes.

@sathya is there a way to test the behavior of the transceiver excluding issues with the antenna? Something like testing the module. Homegear sees two devices (I think one is a “central” since I can issue commands like pon and poff, while the other one can send packets). I’m kind of lost and would like to know if it’s better to test the physical connections or try a different OS.

Thanks!
Daniele

#8

Hey Daniele,

first, post me the settings in your physicalinterfaces.conf to see if everything is allright there. If it is, the SPI communication can be debugged by enabling debuglevel 6 in main.conf.

#9

Hello again,

preamble: I have to issue the command

in order for the device /dev/spidev0.0 and /dev/spidev0.1 to appear.

Physicalinterface.conf reads:

[MAX]
deviceType = cc1100
device = /dev/spidev0.0
responseDelay = 45
# "0" if GDO0 is connected to GPIO of Rasberry Pi or "2" if GDO2 is connected
# You only need one GDO (0 or 2), it doesn't matter which one you use.
interruptPin = 0
# GPIO pin on Raspberry Pi the GDO of the module is connected to.
gpio1 = 1

At this point if I start homegear I get the following output:

# /etc/
init.d/homegear start
12/28/14 16:12:12.404 Info: Loading family module mod_philipshue.so
12/28/14 16:12:12.415 Info: Loading family module mod_max.so
12/28/14 16:12:12.428 Info: Loading family module mod_homematicbidcos.so
12/28/14 16:12:12.446 Info: Loading family module mod_insteon.so
12/28/14 16:12:12.458 Info: Loading family module mod_homematicwired.so
12/28/14 16:12:12.475 Error in file Modules/Base/Systems/IPhysicalInterface.cpp line 649 in function virtual void BaseLib::Systems::IPhysicalInterface::setGPIOEdge(uint32_t, BaseLib::Systems::IPhysicalInterface::GPIOEdge::Enum): Could not write to edge file (/sys/class/gpio/gpio1/edge) of GPIO with index 1: No such file or directory
12/28/14 16:12:12.475 Error in file Modules/Base/Systems/IPhysicalInterface.cpp line 649 in function virtual void BaseLib::Systems::IPhysicalInterface::setGPIOEdge(uint32_t, BaseLib::Systems::IPhysicalInterface::GPIOEdge::Enum): Could not write to edge file (/sys/class/gpio/gpio1/edge) of GPIO with index 1: No such file or directory
12/28/14 16:12:12.476 Info: Disposing family module mod_philipshue.so
12/28/14 16:12:12.476 Info: Disposing family module mod_max.so
12/28/14 16:12:12.477 Info: Disposing family module mod_insteon.so
12/28/14 16:12:12.477 Info: Disposing family module mod_homematicwired.so
12/28/14 16:12:12.478 Info: Disposing family module mod_homematicbidcos.so
[....] Starting Homegear: homegear12/28/14 16:12:12.524 Loading RPC server settings from /etc/homegear/rpcservers.conf
12/28/14 16:12:12.526 Loading RPC client settings from /etc/homegear/rpcclients.conf
. ok

And if fact the edge file is not there:

# ls -lah /sys/class/gpio/gpio1/
total 0
drwxr-xr-x 3 root     root        0 Jan  1 01:02 .
drwxr-xr-x 4 root     root        0 Jan  1 01:00 ..
-rw-r--r-- 1 root     root     4.0K Jan  1 01:05 active_low
lrwxrwxrwx 1 root     root        0 Jan  1 01:05 device -> ../../../gpio-sunxi
-rw-r--r-- 1 root     root     4.0K Jan  1 01:02 direction
drwxr-xr-x 2 root     root        0 Jan  1 01:05 power
-rw-r--r-- 1 root     root     4.0K Jan  1 01:05 pull
lrwxrwxrwx 1 root     root        0 Jan  1 01:02 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root     root     4.0K Jan  1 01:02 uevent
-r--r----- 1 homegear homegear 4.0K Jan  1 01:02 value

I don’t see any traffic in the log, even at debuglevel 10. But homegear.err is empty and in the homegear.log file I see:

12/28/14 16:12:12.681 Module MAX: Loading XML RPC devices...
12/28/14 16:12:12.789 Info: Not initializing device family Philips hue, because no physical interface was found.
12/28/14 16:12:12.790 Loading devices...
12/28/14 16:12:12.791 Module MAX: Loading device 3
12/28/14 16:12:12.793 Module MAX: Loading device 4
12/28/14 16:12:12.795 Start listening for packets...

If I connect (homegear -r) and look around I see this:

> families list
   ID │ Name                          
──────┼───────────────────────────────
    4 │ MAX!                          
──────┴───────────────────────────────
> families select 4
Device family "MAX!" selected.
For information about the family's commands type: "help"
(Family)> devices list
      ID │ Address │ Serial Number │     Type
─────────┼─────────┼───────────────┼─────────
       3 │  FD3D45 │    VMC4265713 │ FFFFFFFD
       4 │  FEB8BA │    VMS6191689 │ FFFFFFFE
─────────┴─────────┴───────────────┴─────────
(Family)> devices select 3
Device selected.
For information about the device's commands type: "help"
(Device)> help
List of commands (shortcut in brackets):

For more information about the indivual command type: COMMAND help

pairing on (pon)	Enables pairing mode
pairing off (pof)	Disables pairing mode
peers list (ls)		List all peers
peers remove (prm)	Remove a peer (without unpairing)
peers select (ps)	Select a peer
peers setname (pn)	Name a peer
peers unpair (pup)	Unpair a peer
unselect (u)		Unselect this device
(Device)> devices select 4
Device selected.
For information about the device's commands type: "help"
(Device)> help
List of commands:

For more information about the indivual command type: COMMAND help

enable			Enables the device if it was disabled
disable			Disables the device
filters list		Lists all packet filters
filters add		Adds a packet filter
filters remove		Removes a packet filter
send			Sends a MAX packet
(Device)>

But, as sayed before: I can’t see anything in the log even at debuglevel10.

At this point if I issue the command

#homegear -s root root

I start seeing packets in the log!

At debug level 4 I see nothing until I initialize pairing from the valve, at this point I see:

12/28/14 16:19:50.564 Module MAX: Warning: Tried to import MAX packet larger than 200 bytes.
12/28/14 16:19:50.563 MAX packet received (cc1100): 09000000000000000000
12/28/14 16:19:55.563 MAX packet received (cc1100, RSSI: 0x3A): 85C5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C85BC5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C8C85BC5F44158
12/28/14 16:19:55.563 MAX packet received (cc1100, RSSI: 0x67): 2DC5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5
12/28/14 16:20:00.563 MAX packet received (cc1100, RSSI: 0x34): 86C5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C85BC5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C8C85BC5F4415821
12/28/14 16:20:00.564 Module MAX: Warning: Tried to import MAX packet larger than 200 bytes.
12/28/14 16:20:00.564 MAX packet received (cc1100): 09000000000000000000
12/28/14 16:20:05.563 MAX packet received (cc1100, RSSI: 0x34): 86C5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C85BC5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C8C85BC5F4415821
12/28/14 16:20:05.564 Module MAX: Warning: Tried to import MAX packet larger than 200 bytes.
12/28/14 16:20:05.564 MAX packet received (cc1100): 09000000000000000000
12/28/14 16:20:10.564 MAX packet received (cc1100, RSSI: 0x4D): 88C5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C85BC5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C8C85BC5F44158212DED
12/28/14 16:20:10.564 Module MAX: Warning: Tried to import MAX packet larger than 200 bytes.
12/28/14 16:20:10.564 MAX packet received (cc1100): 09000000000000000000
12/28/14 16:20:15.564 MAX packet received (cc1100, RSSI: 0x3A): 85C5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C85BC5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C4A8824BC4F9A6F123B045DC333D9A3D7B2C8C85BC5F44158
12/28/14 16:20:15.564 MAX packet received (cc1100, RSSI: 0x25): 2DC5F44158212DEDF9F126EB1E8F7203108F995977E58D33F56F617F1C571AB6C80093728862E12403B7094C0C9C
12/28/14 16:20:15.565 MAX packet received (cc1100, RSSI: 0x67): 88C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5

At debug level 5, even when not pairing, the logfile is flooded (literally) with:

12/28/14 16:22:31.568 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.568 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.568 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.568 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.569 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.569 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.569 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.569 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.570 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.570 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.570 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.571 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.571 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.571 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:22:31.572 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.

At debuglevel 6

12/28/14 16:23:18.160 Module MAX: TI CC110X "cc1100": Debug: Sending: 3A
12/28/14 16:23:18.160 Module MAX: TI CC110X "cc1100": Debug: Received: 1F
12/28/14 16:23:18.161 Module MAX: TI CC110X "cc1100": Debug: Sending: 34
12/28/14 16:23:18.161 Module MAX: TI CC110X "cc1100": Debug: Received: 1F
12/28/14 16:23:18.161 Module MAX: TI CC110X "cc1100": Debug: Sending: F300
12/28/14 16:23:18.161 Module MAX: TI CC110X "cc1100": Debug: Received: 1000
12/28/14 16:23:18.161 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:23:18.161 Module MAX: TI CC110X "cc1100": Debug: Sending: 3A
12/28/14 16:23:18.162 Module MAX: TI CC110X "cc1100": Debug: Received: 1F
12/28/14 16:23:18.162 Module MAX: TI CC110X "cc1100": Debug: Sending: 34
12/28/14 16:23:18.162 Module MAX: TI CC110X "cc1100": Debug: Received: 1F
12/28/14 16:23:18.162 Module MAX: TI CC110X "cc1100": Debug: Sending: F300
12/28/14 16:23:18.162 Module MAX: TI CC110X "cc1100": Debug: Received: 1000
12/28/14 16:23:18.163 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.
12/28/14 16:23:18.163 Module MAX: TI CC110X "cc1100": Debug: Sending: 3A
12/28/14 16:23:18.163 Module MAX: TI CC110X "cc1100": Debug: Received: 1F
12/28/14 16:23:18.163 Module MAX: TI CC110X "cc1100": Debug: Sending: 34
12/28/14 16:23:18.163 Module MAX: TI CC110X "cc1100": Debug: Received: 1F
12/28/14 16:23:18.163 Module MAX: TI CC110X "cc1100": Debug: Sending: F300
12/28/14 16:23:18.164 Module MAX: TI CC110X "cc1100": Debug: Received: 1000
12/28/14 16:23:18.164 Module MAX: TI CC110X "cc1100": Debug: MAX! packet received, but CRC failed.

I hope to have provided what’s needed!

Kind regards,
Daniele

#10

There’s your problem. The missing edge file means, the GPIO is not connected to the interrupt controller. That’s why it’s not working.

First try to export all your GPIOs and see if there is one already having the “edge” file. If there is, connect GDO0 to that GPIO and everything should work.
If not, you need another GPIO driver. See if there are other GPIO drivers available by searching for module files containing “gpio”: “find / -iname gpio.ko”. Unexport all GPIOs, unload the currently used GPIO driver and load the found one (gpio_sunxi.ko for example seems to be a working driver for the A10, see link below). Then again, export all GPIOs and see if there is one having the file “edge”. If there is not, you need to google for something like “banana pi gpio interrupt controller”.

Maybe this post helps, too: http://www.cubieforums.com/index.php/topic,253.30.html

Cheers,

Sathya

#11

Allright, I changed distro to raspbian (for bananapi) which has the gpio utility. I have a different error now. But first some background info:

# gpio readall
+----------+-Rev2-+------+--------+------+-------+
| wiringPi | GPIO | Phys | Name   | Mode | Value |
+----------+------+------+--------+------+-------+
|      0   |  17  |  11  | GPIO 0 | ALT4 | Low   |
|      1   |  18  |  12  | GPIO 1 | ALT0 | High  |
|      2   |  27  |  13  | GPIO 2 | ALT4 | Low   |
|      3   |  22  |  15  | GPIO 3 | ALT4 | Low   |
|      4   |  23  |  16  | GPIO 4 | OUT  | High  |
|      5   |  24  |  18  | GPIO 5 | OUT  | Low   |
|      6   |  25  |  22  | GPIO 6 | ALT4 | Low   |
|      7   |   4  |   7  | GPIO 7 | IN   | Low   |
|      8   |   2  |   3  | SDA    | ALT5 | Low   |
|      9   |   3  |   5  | SCL    | IN   | High  |
|     10   |   8  |  24  | CE0    | ALT5 | Low   |
|     11   |   7  |  26  | CE1    | ALT5 | Low   |
|     12   |  10  |  19  | MOSI   | ALT5 | Low   |
|     13   |   9  |  21  | MISO   | ALT5 | Low   |
|     14   |  11  |  23  | SCLK   | ALT5 | Low   |
|     15   |  14  |   8  | TxD    | ALT0 | Low   |
|     16   |  15  |  10  | RxD    | ALT2 | Low   |
|     17   |  28  |   3  | GPIO 8 | ALT2 | Low   |
|     18   |  29  |   4  | GPIO 9 | IN   | Low   |
|     19   |  30  |   5  | GPIO10 | OUT  | High  |
|     20   |  31  |   6  | GPIO11 | IN   | Low   |
+----------+------+------+--------+------+-------+

I perform the following command using the number which is in the “Phys column”:

# gpio export 12 out
# gpio exports
GPIO Pins exported:
  12: out  0  none 
# ls /sys/class/gpio/gpio12
active_low  device  direction  edge  power  pull  subsystem  uevent  value

The edge file is there, and I modified the phyisicalinterfaces.conf acoordingly:

[MAX]
deviceType = cc1100
device = /dev/spidev0.0
responseDelay = 45
# "0" if GDO0 is connected to GPIO of Rasberry Pi or "2" if GDO2 is connected
# You only need one GDO (0 or 2), it doesn't matter which one you use.
interruptPin = 0
# GPIO pin on Raspberry Pi the GDO of the module is connected to.
gpio1 = 12

And now when starting homegear I get the following in the homegear.err file:

12/28/14 16:20:04.898 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 0.
12/28/14 16:20:04.898 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 1.
12/28/14 16:20:04.899 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 2.
12/28/14 16:20:04.899 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 3.
12/28/14 16:20:04.899 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error writing to register 4.
12/28/14 16:20:04.899 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 5.
12/28/14 16:20:04.900 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error writing to register 6.
12/28/14 16:20:04.900 Module MAX: TI CC110X "cc1100": Error in file Modules/MAX/PhysicalInterfaces/TICC1100.cpp line 558 in function uint8_t MAX::TICC1100::writeRegister(MAX::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 7.
...
...

Thanks a lot for your help, I am truly a noob wrt gpio etc. But I’m learning a lot!

Daniele

#12

Hey Daniele,

now the SPI communication is not working. Does the device “/dev/spidev0.0” exist? What SPI driver is being used? The default Raspbian driver (spi_bcm2708) does not work with the A20.

Regards,

Sathya

#13

Hi sathya,

the module is spi_sun7i.ko.
There are two spi-related files in /dev: /dev/spidev0.0 and /dev/spidev0.1

Could it be that the GPIO pin is not the right one? I am not sure whether I should use the physical pin number to export the GPIO (I did so).

Thanks and regards,
Daniele

#14

[quote]the module is spi_sun7i.ko.
There are two spi-related files in /dev: /dev/spidev0.0 and /dev/spidev0.1[/quote]

ok, looks good.

No, now it’s not a GPIO problem as long as you didn’t connect GDO0 to the SPI pins. Does “gpio readall” still output “Low” for “CE0” and “CE1”?? That’s wrong. Both need to be “High”. Maybe try googling “banana pi raspbian spi howto” to see, if there is something else that needs to be done.

#15

I’m going back to bananian (which uses a more recent kernel) since now I know how to manipulate the GPIO pins without the gpio binary. With it the SPI seemed to work (at least I’ve seen some packets).

Thanks a lot.

#16

AAAAND it works with bananian!!! I paired succesfully with the first thermostatic valve!

      ID │ Name                      │ Address │ Serial Number │ Type │ Type String               │ Firmware │ Unreach
─────────┼───────────────────────────┼─────────┼───────────────┼──────┼───────────────────────────┼──────────┼────────
         │                           │         │               │      │                           │          │        
       1 │                           │  106633 │    LKF00XXXXX │ 01A0 │           BC-RT-TRX-CyG-3 │      1.0 │      No
─────────┴───────────────────────────┴─────────┴───────────────┴──────┴───────────────────────────┴──────────┴────────

Thanks a lot for your help and guidance @sathya!!!

#17

Great :smiley:. How did you get it to work?

#18

Hello again and sorry for the delay in replying. I’m wrapping up everything I did to make homegear work on the bananapi (bananian distro v14.11).

The wiring that I posted earlier in this thread is working, I did no modification to it. There is one issue, though, the PINS identified as GPIO 0, GPIO 1, etc. are not really GPIO 0, GPIO 1, etc. So you cannot simply “export” these IDs and expect things to work. Since bananian does not provide the gpio binary to find out the mapping, I installed raspbian (for the banana pi) and got the mapping you can find in this thread.
If you use the wiring depicted in my previous post, you have to export GPIO 18, since I used the physical pin 12.

Since bananian 14.11 is debian wheezy (don’t ask me why they used a naming a-la ubuntu, I have no idea) I added the debian repository of homegear. Be aware that you need to install perl (which provides rename) and patch (which provides… patch :slight_smile: ), otherwise homegear installation will fail.
Further, bananian is exposing the spi devices in /dev/ with access only for user root, and this means that you have either to change the configuration of homegear in order to make it start, or adapt the OS. I chose the latter approach and did the following:

!!! please don't run random commands you see on the internet on your systems unless you understand them. !!!
# addgroup --system spi #this group will get read and write access to the SPI devices
# adduser homegear spi #we want the user homegear to be part of the spi group we just crerated
# cat > /etc/udev/rules.d/spi-sun7i.rules << EOF
KERNEL=="spi-sun7i*", SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
EOF
#change the udev rules and give to group spi rw access to the spi devices
# add a row to /etc/modules with the following content, so that the spi module gets loaded at boot time 
spi-sun7i

Now edit the physicalinterfaces.conf according to your needs, be sure to use pin 18 (see my posts with the configuration for MAX! devices) if you used my wiring diagram. Homegear should start without troubles, and should be automatically started after boot.

HTH!
Daniele

#19

Hi!

Thanks for providing the details on getting the CC110x running on the Banana Pi with Homegear.
You should really link this thread to the corresponding Homegear wiki page.

I would also like to report success:

  • Using an ELV TRX868-TFK module (the small long one) directly connected to the Banana Pi running Bananian.
  • Used the Debian APT repo from Homegear. I just did a “apt-get install homegear” and after modifying the physicalinterfaces.conf it worked immediately.
  • together with OpenHAB 1.6.2 and Oracle Java 8

Great! :mrgreen:

BR
Nanosonde

#20

Hi, i’ve also a Problem with this Pollin Device.

But for my surprise only on the B and B+ RaspberryPi Models.
On a Pi2 it works perfect.

On a B and B+ Model the log says something like this

02/27/15 18:45:21.122 Module HomeMatic BidCoS: TI CC110X "My-CC1101": Error in file Modules/HomeMaticBidCoS/PhysicalInterfaces/TICC1100.cpp line 665 in function uint8_t BidCoS::TICC1100::writeRegister(BidCoS::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 0. 02/27/15 18:45:21.124 Module HomeMatic BidCoS: TI CC110X "My-CC1101": Error in file Modules/HomeMaticBidCoS/PhysicalInterfaces/TICC1100.cpp line 665 in function uint8_t BidCoS::TICC1100::writeRegister(BidCoS::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 1. 02/27/15 18:45:21.131 Module HomeMatic BidCoS: TI CC110X "My-CC1101": Error in file Modules/HomeMaticBidCoS/PhysicalInterfaces/TICC1100.cpp line 665 in function uint8_t BidCoS::TICC1100::writeRegister(BidCoS::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 2. 02/27/15 18:45:21.133 Module HomeMatic BidCoS: TI CC110X "My-CC1101": Error in file Modules/HomeMaticBidCoS/PhysicalInterfaces/TICC1100.cpp line 665 in function uint8_t BidCoS::TICC1100::writeRegister(BidCoS::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 3. 02/27/15 18:45:21.134 Module HomeMatic BidCoS: TI CC110X "My-CC1101": Error in file Modules/HomeMaticBidCoS/PhysicalInterfaces/TICC1100.cpp line 665 in function uint8_t BidCoS::TICC1100::writeRegister(BidCoS::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 4. 02/27/15 18:45:21.135 Module HomeMatic BidCoS: TI CC110X "My-CC1101": Error in file Modules/HomeMaticBidCoS/PhysicalInterfaces/TICC1100.cpp line 665 in function uint8_t BidCoS::TICC1100::writeRegister(BidCoS::TICC1100::Registers::Enum, uint8_t, bool): Error (check) writing to register 5.

My config

[HomeMaticBidCoS] id = My-CC1101 default = true deviceType = cc1100 device = /dev/spidev0.0 responseDelay = 100 interruptPin = 0 gpio1 = 25

Any suggestions?