Difference between revisions of "FAQ"
| Line 1: | Line 1: | ||
| − | == How do I get access to the testbed ? == | + | |
| + | == Testbed Usage == | ||
| + | |||
| + | === How do I get access to the testbed ? === | ||
This is explained on the [[Getting Started]] page | This is explained on the [[Getting Started]] page | ||
| − | == Why do I get a 'network connection' error when I try to start a test ? == | + | === I can't create links to/from nodes in the CityLab testbed in the JFed interface. === |
| + | |||
| + | We are painfully aware of this limitation, and fixing this is at the top of our TODO list. In the mean time, take a look at the [[GRE Tunnels]] page for a workaround. | ||
| + | |||
| + | === Why do I get a 'network connection' error when I try to start a test ? === | ||
The most likely reason for this is that your host network is blocking outbound TCP connections to port 12369. You can easily work around this by enabling the ''JFed Proxy''. Click [[Getting_Started#Working around connectivity issues| here ]] for more information on how to do so. | The most likely reason for this is that your host network is blocking outbound TCP connections to port 12369. You can easily work around this by enabling the ''JFed Proxy''. Click [[Getting_Started#Working around connectivity issues| here ]] for more information on how to do so. | ||
| − | == | + | == Network Connectivity == |
| − | == | + | === Why Is the MTU on the wired (control) interface 1462 instead of 1500 bytes ? === |
| − | + | The Emulab testbed management software we use to manage the testbed expects all ''test nodes'' to be connected to a single L2-segment (VLAN). As can be seen on the [https://doc.lab.cityofthings.eu/nodemap/ node map] website however the CityLab nodes are installed on different buildings in the City Center and therefore also connected to different L3-networks. To resolve this issue, the L2 traffic from the individual nodes is ''tunneled'' to a concentrator in our server room using a setup not unlike the one discussed [[GRE Tunnels#Creating a link between three or more nodes|here]]. | |
| + | |||
| + | This does however incur a 38-byte tunnelling overhead for each packet. To prevent fragmentation of the (outer) IP-packet, the MTU inside the tunnel, and therefore the entire L2 segment, is capped to 1462 bytes. | ||
| + | |||
| + | === UDP packets get lost and TCP sessions hang when I bridge a GRE-Tunnel to a WiFi interface. === | ||
| + | |||
| + | This is probably because the MTU configured on the WiFi clients does not match the MTU of the GRE Tunnel. See [[GRE Tunnels#Reduced MTU here|this page]] for more information on how to solve this. | ||
| + | |||
| + | == Embedded Radios == | ||
| − | == How do I know which serial interface (/dev/ttyUSBX) is connected to what device? == | + | === How do I know which serial interface (/dev/ttyUSBX) is connected to what device? === |
If you use one of the 'CoT' [[Disk Images]], symlinks are automatically created in '/dev' that will allow you to identify each serial port: | If you use one of the 'CoT' [[Disk Images]], symlinks are automatically created in '/dev' that will allow you to identify each serial port: | ||
| Line 26: | Line 41: | ||
If you are not using one of the 'CoT' images, you can add the necessary udev-rules needed to to do by copying <code>/etc/udev/rules.d/50-persistent-usb.rules</code> from one of the 'CoT' images to your own image. | If you are not using one of the 'CoT' images, you can add the necessary udev-rules needed to to do by copying <code>/etc/udev/rules.d/50-persistent-usb.rules</code> from one of the 'CoT' images to your own image. | ||
| − | == How can I flash/erase the EZRUSB devices ? == | + | === How can I flash/erase the EZRUSB devices ? === |
If you use one of the 'CoT' Disk Images, the EZRUSB devices can be programmed using the <code>flash_ezr</code> script. | If you use one of the 'CoT' Disk Images, the EZRUSB devices can be programmed using the <code>flash_ezr</code> script. | ||
| Line 43: | Line 58: | ||
You can add these scripts to your own image by simply copying them from the <code>/usr/local/bin</code> directory from one of the 'CoT'-images to your own image, but to run them OpenOCD (0.9.0 or later) does need to be installed. | You can add these scripts to your own image by simply copying them from the <code>/usr/local/bin</code> directory from one of the 'CoT'-images to your own image, but to run them OpenOCD (0.9.0 or later) does need to be installed. | ||
| − | == How can I flash/erase the LoRa device ? == | + | === How can I flash/erase the LoRa device ? === |
The 'LoRa' device is basically a Giant Gecko [https://www.silabs.com/products/development-tools/mcu/32-bit/efm32-giant-gecko-starter-kit starter kit] equipped with an RFM95W LoRa module. (See [Node Specifications]). This module is equipped with an on-board [https://www.segger.com/products/debug-probes/j-link/ J-Link debugger], so debugging/programming/erasing this board is done in exactly the same way as it is for any other SiLabs MCU. (See [https://www.silabs.com/support/getting-started/microcontrollers/efm32-mcu here] for the offical 'Getting Started' guides. | The 'LoRa' device is basically a Giant Gecko [https://www.silabs.com/products/development-tools/mcu/32-bit/efm32-giant-gecko-starter-kit starter kit] equipped with an RFM95W LoRa module. (See [Node Specifications]). This module is equipped with an on-board [https://www.segger.com/products/debug-probes/j-link/ J-Link debugger], so debugging/programming/erasing this board is done in exactly the same way as it is for any other SiLabs MCU. (See [https://www.silabs.com/support/getting-started/microcontrollers/efm32-mcu here] for the offical 'Getting Started' guides. | ||
| Line 59: | Line 74: | ||
If you are not using one of the 'CoT'-images, you first need to install the '''[https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack J-Link Software And Documentation Pack]''' for your specific operating system. Once this package is installed you can add the <code>flash_lora</code> and <code>erase_lora</code> scripts to your image to make flashing and erasing the device a bit easier. These scripts can be found in the <code>/usr/local/bin</code> directory in any of the 'CoT' disk images. | If you are not using one of the 'CoT'-images, you first need to install the '''[https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack J-Link Software And Documentation Pack]''' for your specific operating system. Once this package is installed you can add the <code>flash_lora</code> and <code>erase_lora</code> scripts to your image to make flashing and erasing the device a bit easier. These scripts can be found in the <code>/usr/local/bin</code> directory in any of the 'CoT' disk images. | ||
| − | == I have a question and I can't find the answer on the Wiki == | + | == Miscellaneous == |
| + | |||
| + | === I have a question and I can't find the answer on the Wiki === | ||
Please send your question to {{SafeMailTo|admin|lab.cityofthings.eu}}. We'll be happy to help you along and update the documentation where necessary. | Please send your question to {{SafeMailTo|admin|lab.cityofthings.eu}}. We'll be happy to help you along and update the documentation where necessary. | ||
Revision as of 12:22, 13 March 2018
Testbed Usage
How do I get access to the testbed ?
This is explained on the Getting Started page
I can't create links to/from nodes in the CityLab testbed in the JFed interface.
We are painfully aware of this limitation, and fixing this is at the top of our TODO list. In the mean time, take a look at the GRE Tunnels page for a workaround.
Why do I get a 'network connection' error when I try to start a test ?
The most likely reason for this is that your host network is blocking outbound TCP connections to port 12369. You can easily work around this by enabling the JFed Proxy. Click here for more information on how to do so.
Network Connectivity
Why Is the MTU on the wired (control) interface 1462 instead of 1500 bytes ?
The Emulab testbed management software we use to manage the testbed expects all test nodes to be connected to a single L2-segment (VLAN). As can be seen on the node map website however the CityLab nodes are installed on different buildings in the City Center and therefore also connected to different L3-networks. To resolve this issue, the L2 traffic from the individual nodes is tunneled to a concentrator in our server room using a setup not unlike the one discussed here.
This does however incur a 38-byte tunnelling overhead for each packet. To prevent fragmentation of the (outer) IP-packet, the MTU inside the tunnel, and therefore the entire L2 segment, is capped to 1462 bytes.
UDP packets get lost and TCP sessions hang when I bridge a GRE-Tunnel to a WiFi interface.
This is probably because the MTU configured on the WiFi clients does not match the MTU of the GRE Tunnel. See this page for more information on how to solve this.
Embedded Radios
How do I know which serial interface (/dev/ttyUSBX) is connected to what device?
If you use one of the 'CoT' Disk Images, symlinks are automatically created in '/dev' that will allow you to identify each serial port:
- OpenUSB:
/dev/ttyOPENUSB - EZRUSB@433 MHz:
/dev/ttyEZR433 - EZRUSB@868 MHz:
/dev/ttyEZR868 - EFM32GG+LoRa:
/dev/ttyLORA
By referring to these symlinks instead of the /dev/ttyUSBX-devices directly you can be sure that you are talking to the correct device.
If you are not using one of the 'CoT' images, you can add the necessary udev-rules needed to to do by copying /etc/udev/rules.d/50-persistent-usb.rules from one of the 'CoT' images to your own image.
How can I flash/erase the EZRUSB devices ?
If you use one of the 'CoT' Disk Images, the EZRUSB devices can be programmed using the flash_ezr script.
This script can be invoked as follows:
flash_ezr <device> <elf-file>
Where:
<device>is one of 'EZR433' or 'EZR868', depending on whether you want to flash the 433MHz or 868MHz device<elf-file>is the ELF-image to flash to the device.
Likewise, the erase_ezr script can be used to erase an EZRUSB device. This script is invoked in exactly the same way as the flash_ezr script, except that no ELF-image file is specified.
Even if you are not using one of the 'CoT' images, you are strongly advised to use the flash_ezr and erase_ezr scripts since these scripts contain the logic required to ensure that the 'correct' device is flashed/erased.
You can add these scripts to your own image by simply copying them from the /usr/local/bin directory from one of the 'CoT'-images to your own image, but to run them OpenOCD (0.9.0 or later) does need to be installed.
How can I flash/erase the LoRa device ?
The 'LoRa' device is basically a Giant Gecko starter kit equipped with an RFM95W LoRa module. (See [Node Specifications]). This module is equipped with an on-board J-Link debugger, so debugging/programming/erasing this board is done in exactly the same way as it is for any other SiLabs MCU. (See here for the offical 'Getting Started' guides.
To make things a bit easier, all 'CoT' disk images already contain the necessary J-Link software as well as a few helper scripts.
Flashing the 'LoRa'-device can be done using the flash_lora script.
This script is invoked as follows:
flash_lora <device> <elf-file>
Where:
<elf-file>is the ELF-image to flash to the device.
Likewise, the erase_lora script can be used to erase the 'LoRa-'device. This script is invoked in exactly the same way as the flash_lora script, except that no ELF-image file is specified.
If you are not using one of the 'CoT'-images, you first need to install the J-Link Software And Documentation Pack for your specific operating system. Once this package is installed you can add the flash_lora and erase_lora scripts to your image to make flashing and erasing the device a bit easier. These scripts can be found in the /usr/local/bin directory in any of the 'CoT' disk images.
Miscellaneous
I have a question and I can't find the answer on the Wiki
Please send your question to . We'll be happy to help you along and update the documentation where necessary.