I've bought a Raspberry Pi 3B+(more precisely: the starter kit ABOX Raspberry Pi 3 B+ Kit) and installed Raspbian on it. I connected the Raspberry with the internet by using it's wlan adapter and I tried it also with a Fritzbox Wlan Stick N. The problem is that whenever I need to use the internet connection on both devices both are slowed down dramatically.
The strange thing is that my smartphone seems not to be affected nor affects any of the other connections. This only happens when my main computer (Windows 10) and my Raspberry are trying to use some service on the internet at the same time
Can anyone help me with this? Any help is appreciated
I had the same problem with my RPI, and it turned out to be the Power Management feature.
You can try disabling it:
sudo iwconfig wlan0 power off
If it worked, you can add this command to your rc.local file
Related
I want to know whether Raspberry Pi 2 support ThingsBoard platform? Can I just follow the steps of installing ThingsBoard for RPi3 and will it work for RPi2 also?
It looks like it is supported. based on this link: https://thingsboard.io/docs/samples/raspberry/gpio/ :
Raspberry Pi - we will use Raspberry Pi 3 Model B but you can use any other model.
Also, support is mainly related to what protocols are available and supported by the platform:
https://thingsboard.io/docs/reference/protocols/
MQTT
CoAP
HTTP
We are currently running ThingsBoard gateway in a Raspberry Pi 2 model B, so I can confirm it is fully supported. Installed following the official guide here, with Raspbian Stretch Headless as operating system.
I am trying to build an imaging system and I want to use Tensorflow with Orange pi 4G. Does anyone know if there are limitations, is this possible?
As I can see Orange PI 4g iot is still not compatible with Ubuntu but I hope it will be in the near future. Any information you could give me i will be happy.
Official CI server for Tensorflow has some nightly builds with python wheels for raspberry pi armv7l, it is not officially supported by tensorflow yet, they officially support only 64-bit architectures so far, but I managed to get yolo-keras working on "orange pi pc plus" using their nightly build wheel file.
You can also find the scripts they used for building the wheel (actually it's cross-built using a docker container) in directory tensorflow/tensorflow/tools/ci_build inside source code.
Some people also provided guides for native building, but it generally requires more effort to get it to work.
I suggest you start by trying the python wheel file for tensorflow v1.8.0 for raspberry pi armv7l architecture, found here.
I've been doing a lot of Raspberry Pi work, but that means I have to carry about my Pi (or SSH home), and well, the Pi isn't the fastest in the world. I've been using Docker for running things like Postgres, and was thinking it would be awesome to just download a Docker image of the ARM build of Debian Jessie, and have everything function as if it was actually running in a real rPi. Even better if I could just somehow then quickly mirror this to an SD card and throw it into a real rPi.
Has anyone explored this? Everything I'm finding is about running Docker on the rPi, not running Docker to emulate an rPi.
Based on the answers and comments to similar questions - such as this one on the Raspberry Pi Stack Exchange site I think that the short answer to "no" (or at least not without a lot of effort)
Your problem is that as mentioned in the comments Docker doesn't do full-on virtualisation (that's kind of the point of it) so you can't get an ARM Raspbian Docker image and run it on an x86 Virtualbox host - which is what it sounds like you'd like to do.
The Docker image needs to be built for the same architecture as the host system. you get the same problem if you try to run x86 Docker images on the Raspberry Pi if it is acting as a Docker host.
By way of a solution - what I'd suggest is running a Debian VM on your Mac. Raspbian is close enough to Debian that you'll have a fairly "Pi-like" environment to develop in and can copy your code to an SD card when you're done.
If you want an easy way to manage the configuration so that the number of cores, RAM, disk space etc matches your Pi, then Vagrant may be a good solution.
I'm working on a prototype on which I need to create a peer-to-peer video chat between a Raspberry Pi equipped with a Raspberry Cam and an iOS device using Twilio. The iOS part was easy but I can't find a way to do the same on the Raspberry. Is that even possible?
Thanks.
I've not tried this, but it seems like you would have to rely on the browser capabilities of the Pi. The current standard there seems to be the Epiphany browser which you'd get with the following commands:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install epiphany-browser
Then you can check whether that browser would support using Twilio Client:
https://www.twilio.com/docs/quickstart/php/client
Alternatively, if for whatever reason it would not work with Twilio Client, you could still use the Pi as a WebRTC device via other methods as modeled in this blog post.
I don't have a Raspberry Pi 2 or camera to test this with so let me know if this helps at all.
Hi everyone I downloaded the ISO file for investigating SDN features from here: http://sdnhub.org/tutorials/sdn-tutorial-vm/.
1) I run Mininet
sudo mn
to make basic topology
2) Then I run wireshark
sudo wireshark &
3) I tick all interfaces and start capturing
4) In mininet I do
h1 ping h2
5) I apply filter in wireshark "openflow", "of",....
6) But no OpenFlow packet are displayed
Could you help me please what is wrong? Thanks
It would help to know where the controller is running. Is it a remote controller running in your host OS, or a controller running in the Mininet VM? Because you've run the basic topology, I'm going to answer based on the assumption that you're running the simulation over the basic ovs-controller that's enabled by default which runs within the VM.
Looks like you've run Wireshark from your host OS and not on Mininet. You made sure that you're listening on all the interfaces, good. But if the controller was running in the Mininet VM, these interfaces would have nothing to do with the OF packets and hence would not capture them. To actually capture the OF packets if the controller is in the Mininet VM, you've got to run an instance from the VM.
For me, openflow_v4 filter worked.
Try selecting only the loopback interface: lo