Hello all!
I am trying to control a Roku from a Raspberry Pi. I know that I could use the included Roku remote as well as the app on my phone, but I plan to control much more with the Pi. I built a PHP webpage with buttons that execute Python scripts to send commands to the Roku (i.e. menu functions, navigation arrows). However alit takes about 2-3 seconds for the command to work (versus instantaneous from remote or app). I bypassed the web server on my Pi and run the Python scripts directly in the shell, but still experiencing delayed control. Thinking it was a wifi induced delay, I connected the Pi’s wired NIC to the same switch as my Roku (same subnet). Still delayed. Is this a hardware limitation or am I doing something wrong? Thanks in advance!
I would say that it's possibly a hardware limitation. I would say to try to run it in verbose to see how long the response time is and see if it's timing out or something like that. Just a possibility, but potentially the issue. Also, it probably doesn't matter, but what Pi model are you running also?
NTGDeveloper said:
I would say that it's possibly a hardware limitation. I would say to try to run it in verbose to see how long the response time is and see if it's timing out or something like that. Just a possibility, but potentially the issue. Also, it probably doesn't matter, but what Pi model are you running also?
Click to expand...
Click to collapse
Thanks for your response! I’ve got a 3B+. Not the latest but not too old either. I’ll give verbose a shot to see how long it takes for a response. I may also try (if possible) running commands directly thru Putty. It doesn’t get any more direct than that. I’m hoping it’s not a hardware limit but for $35, sheesh, I can’t complain too much!
Related
I have a robot lawnmower, Friendly Robotics Robomow RL500. It's like a Roomba for the lawn, you set it loose and let it go. Problem is, it's not very smart. For one, it gets stuck on occasion, requiring me to check on it regularly and free it if it gets stuck. It also needs to be driven out onto the lawn and turned on, and when it's done I need to go find it and drive it back. Worst of all, there is a part of the lawn that is too narrow for it to function automatically so I have to manually mow that part with an annoying wired controller, and it is much slower than a regular mower so walking behind it at a snail's pace holding a wired controller is very boring.
My idea is to make it so I can put a camera on it so I can drive it via Wifi from the comfort of my home. Somehow I will need to be able to stream video over Wifi and send commands to the robot as well, and whatever device receiving the commands will need to be able to activate the switches on the wired controller.
2 ways I thought of to do this:
1. Use one of my extra Windows Mobile phones as a "brain". They all already have a camera and Wifi. All I would need is the software to stream video over Wifi and a control program to control the robot. Microsoft has a Robotics Studio that may help me to write my own program using VS.NET. None of my phones have a serial port or USB Host controller, so I was thinking maybe I can use a Bluetooth-to-UART board and connect that to some kind of controller to activate the switches on the control panel.
2. Use a WRT54G and run Linux. This will probably cost more because I don't have a 54G. I will also need to buy some kind of camera for it, like a networked camera. It has an RS232 port that can be used to connect to some kind of controller to activate switches on the control panel. I KNOW this solution has been done, because there is a video out there of a 54G-controlled R/C car being controlled via Wifi and streaming video back. I would probably need to write my own program in C in Linux (I don't know C), unless I can find the link to that RC car again and see if that guy will share his source.
Any thoughts on which way is the best way to go?
Jejeje
Try this
http://www.youtube.com/watch?v=GaquxmK-kp4
Has anyone seen or heard of possibly using an old smartphone touchscreen as a monitor for the pi?
Seems like everyone has old spare phones laying around. Maybe the adaptation is too difficult, but thought I'd just put it out there.
VNC Is the solution!
Lemmiwinx said:
Has anyone seen or heard of possibly using an old smartphone touchscreen as a monitor for the pi?
Seems like everyone has old spare phones laying around. Maybe the adaptation is too difficult, but thought I'd just put it out there.
Click to expand...
Click to collapse
I suggest you to setup a VNC Server on the raspberry pi, download a VNC Client on the smartphone, and connect the client to the server. Now you will be able to use your touch phone as both screen, mouse and keyboard for the raspberry pi. You can also just use it as a screen, but it will be pretty low resolution, depending on how large the screen is.
If you don't know what VNC is, it is basically a "remote screen control thing", as I like to call it.
Check out some links here:
Phone VNC Client (Android): play.google.com/store/apps/details?id=android.androidVNC&hl=en
VNC Server for Raspberry Pi: gettingstartedwithraspberrypi.tumblr.com/post/24142374137/setting-up-a-vnc-server
Just a tip, lol.
(Any questions/problems setting up vnc, pm me or email me: [email protected])
-Mpb907#
Source: en.wikipedia.org/wiki/Vnc
MpB907 said:
I suggest you to setup a VNC Server on the raspberry pi, download a VNC Client on the smartphone, and connect the client to the server. Now you will be able to use your touch phone as both screen, mouse and keyboard for the raspberry pi. You can also just use it as a screen, but it will be pretty low resolution, depending on how large the screen is.
If you don't know what VNC is, it is basically a "remote screen control thing", as I like to call it.
Check out some links here:
Phone VNC Client (Android): play.google.com/store/apps/details?id=android.androidVNC&hl=en
VNC Server for Raspberry Pi: gettingstartedwithraspberrypi.tumblr.com/post/24142374137/setting-up-a-vnc-server
Just a tip, lol.
(Any questions/problems setting up vnc, pm me or email me: [email protected])
-Mpb907#
Source: en.wikipedia.org/wiki/Vnc
Click to expand...
Click to collapse
I was thinking more of inline of just hardware. Ive got a GS3 that bricked, so i was thinking of taking apart and hooking up the screen that way. plus ive got another half dozen phones that arent in use. Didnt know if anyone ever tried it before, seems like such an obvious idea.
Not from a smartphone but you can search for Siemens S65 or Nokia 6610/3310 for Raspberry Pi...
Those are working!
I had not found someone who has got make a smartphone display work...
Gesendet von meinem GT-I9100
So, hardware...
Lemmiwinx said:
I was thinking more of inline of just hardware. Ive got a GS3 that bricked, so i was thinking of taking apart and hooking up the screen that way. plus ive got another half dozen phones that arent in use. Didnt know if anyone ever tried it before, seems like such an obvious idea.
Click to expand...
Click to collapse
I don't really know what to do here, but I saw some people hook up a broken smartphone (With working screen) to the raspberry pi via GPIO cables.
Maybe this'll help you: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=34469
If you know what you are doing then I do not think it should be any problem to do so.
I was looking for something like this, because I have some old phones with good screens that would come in handy as status screens (I'm already using VNC)
¿Has someone tried to drive any phone screen with the bare GPIO or is a shield needed?
Thanks for the link. Its definitely going to work for one of my many pi projects. Love this this community !
So, got a question...
How hard would it be/would it be possible to cross-compile a media player for the cc (something that can be run from CLI like vlc), put it on an external storage device (if cc recognizes a connected USB device while the rom is running - maybe eureka rom, bhiga?), mount a samba share, and play a wider variety of movie formats.
So the solution would look something like this...
1. Put vlc binary on flash drive connected to cc via powered OTG cable
2. Ssh in to cc
3. Mount network samba share containing videos
4. Play whatever videos from vlc operated by cli over samba, replacing dial
Not really a programmer, and have absolutely no idea how a cc works... But it seems to me that a solution like this, while unwieldy, would allow one to bypass the limitations of cc's implementation of dial.
What do y'all think?
Sent from my SCH-I535 using XDA Premium 4 mobile app
And what about other binaries? Something like apache, php... Maybe turn the cc into a cheap webserver?
Sent from my SCH-I535 using XDA Premium 4 mobile app
I think one of the Team Eureka folks said the USB storage isn't available at normal runtime, but I could be mistaken.
Webserver is definitely possible, as that's what the Eureka Web Panel is, but general-purpose webserver use would be limited by both wireless bandwidth and moreso by the lack of storage (unless USB actually does work),
An important thing to keep in mind here... Unlike Android phones, tablets and TV sticks, Chromecast is much more scaled down and limited in design. I consider phones, tablets and TV sticks as Android-powered devices with the qualification that they are meant to be interacted with, apps installed, expanded, etc.
Think of Chromecast it more of an "accessory," black box or dumb terminal. Chromecast is more of an "extension" to those user-configurable devices.
Remember the ViewSonic AirPanel? Technically it is a computer, but a very limited (embedded) one. While it mirrored the primary screen of the computer, rather than being a second screen, it's a similar model. The AirPanel has some intelligence to accelerate the user experience but the core processing is done on the computer it's attached to.
Neither AirPanel nor Chromecast are meant to be interacted with directly at the device level, or loaded down with a lot of background processes. Chromecast doesn't have an interactive UI of its own, nor does it have external input (keyboard, mouse, touchscreen, etc) like your typical Android device does.
I wouldn't surprised if a number of "standard" libraries that your typical Android platform has simply aren't there.
I'm not saying getting VLC on it is impossible - I really don't know, but I do think it's improbable and would require a great deal of effort.
Without hardware acceleration or SDK/API support, you're relying purely on the software processing, and I haven't found much in the way of detailed specs on the platform itself. I have seen mention of the platform supporting other compression formats that Google isn't supporting yet, like MPEG-2, so it remains to be seen what Google's long-term plans are.
Not trying to be a downer here, just trying to keep things in perspective. After all, Google didn't sell us a $35 PS4 equivalent.
bhiga said:
I think one of the Team Eureka folks said the USB storage isn't available at normal runtime, but I could be mistaken.
Click to expand...
Click to collapse
So, if I'm understanding correctly, this sounds like a software limitation...Clearly the hardware is compatible - Flashcast relies on it. I don't know much about the intricacies of programming for mobile devices, but conceptually it would seem possible to make usb accessible during normal operation if it's accessible to something like Flashcast. I would love to read up on Flashcast more...it's just that normally things like flashcast which are very specific to certain hardware and require exploitation of particular holes/flaws in the software residing on that device are not normally very well documented.
How is it that Flashcast "unlocks" the functionality of USB OTG, and what limits its use when the device is booted normally? Is it something in the bootloader? Does Flashcast "hijack" the bootloader and use a different one?
EDIT: Or even how about something like this: Create an image like the recovery image that's flashed to a USB Drive, except make the "recovery image" a full ROM. That way, ROM gets access to USB device, we have much more room to put other features/binaries, etc, and then there's built in storage...Would something like that work?
tomg09 said:
How is it that Flashcast "unlocks" the functionality of USB OTG, and what limits its use when the device is booted normally? Is it something in the bootloader? Does Flashcast "hijack" the bootloader and use a different one?
EDIT: Or even how about something like this: Create an image like the recovery image that's flashed to a USB Drive, except make the "recovery image" a full ROM. That way, ROM gets access to USB device, we have much more room to put other features/binaries, etc, and then there's built in storage...Would something like that work?
Click to expand...
Click to collapse
As I understand things, FlashCast runs in recovery mode, which uses its own bootloader - which is what allows access to OTG.
If that code isn't in the normal mode bootloader, then OTG won't be accessible. It might be loadable via a kernel module, but it seems the current Android direction is to disallow loading of kernel modules (probably because it's a potential security hole).
There's more information about how and why FlashCast works in the FlashCast thread.
Hey Guys
First of all: I realize that this is a rather long text, so I appreciate the effort of everyone who is going to read it!
Also, I asked a questions about 2 weeks ago, which was related to this topic, but was very specific about android wear (which I gave up on since then!).
So, actual post:
I want to build, or already am building an informational system for my motorcycle.
As the result of my work, I imagine a display (about 7 inches) in the dash of my motorcycle. It shall display information from my Smartphone (for example notifications about incoming calls etc.) as well as giving me the possibility to control the music on the smartphone (Android 5.1).
Also, I want to display further information, like speed, average speed, altitude etc. (hope you got the idea, basically just an advanced trip computer).
I started developing something, but ran into issues. I will explain my two concepts or ideas I had so far and explain, what the issues were I ran into. I then hope, that somebody here has a solution for my problem (which includes recommending hard- and software).
Firstly about my skills: I am experienced in programming "low level hardware", like Atmel's AVR Series (in plain old C) and developing the associated hardware for it. Also making custom pcb's at home isn't a problem for me, as long it doesn't come to some fancy BGA or SMD packages
On the programming side I am experienced the most in Java (and Android, which is basically Java of course). I know also C# and the .NET framework.
But I am willing to learn something new
The two ideas I had so far differed on the way how I wanted to let the raspberry pi (which I wanted to place in the cockpit) communicate with the smartphone.
In both concepts, I planned to have a raspberry pi with attached display in the cockpit on which I wanted to run a JavaFX application (already started programing). This application would then communicate with the smartphone over:
Idea 1: Java serialization:
I wanted to communicate over command objects. So for example I'd have an object for asking the altitude from the smartphone.
I'd then serialize this command object on the pi's side and deserialize on the smartphone. This isn't a problem, because there's java on either side (already got that piece working).
The smartphone would, after receiving and deserializing the object, get the actual altitude from the GPS sensor, pack the result in an answer-object, serialize it and send it back to the pi.
The issues I ran into were the following:
-Java Bluetooth library: I wasn't able to find a good, up-to-date, java library for communicate over Bluetooth in java. I then stuck to RXTX Library which did the job, but I always had the feeling of doing something "not so good". In particular I didn't want to just write on a COM-Port (which is emulated from the Bluetooth-module), because I had the feeling that COM-Ports may change after reboots if the OS feels like it, and I didn't want to build something which needed constant "tinkering". Also, writing to COM-Ports in 2015 just feels wrong, but this may be my personal problem
Idea 2: HTTP and Web Sockets
The basic idea was to have a webserver running on the smartphone and offering a REST-like API which I could access from the pi.
I also got this concept working, like so:
By using the NanoHTTPD library (from github) I was able to start a webserver on the android device. When then someone issued a POST-request on, for example, <IP>:<port>/api/music/next, the WebServer would receive this request and switch to the next song.
Actualizing data on the pi which changes often, for example the altitude, would have been achieved by using a WebSocket connection between the Java-App on the pi and the android webserver (which I also got to work).
I figured out that it would be a power consumption problem to let the smartphone offer a wifi hotspot (I don't want to have to connect the smartphone to cables on the motorcycle), so I decided to let the pi start a wifi access point (which isn't a power problem, because the pi is connected to on-board-power of the motorcycle).
However I then realized that the smartphone won't connect to an access point which doesn't offer internet access but only LAN-access.
And even if there was a way to force the smartphone to let it connect anyways, it isn't guaranteed that this will work too on future devices. And: The whole notification-stuff would have been needless, because as long as the smartphone is connected to a "dead-end wifi", it wouldn't receive emails or whatsapp-messages.
Idea 3: Using Bluetooth low energy:
It seems like the new, modern way, to let devices communicate over Bluetooth is to use Bluetooth low energy (BLE). (But I never worked with it before!).
However, there seems to be little to no support on raspberry pi for it, and it seems to be impossible to find a library for java which helps in using BLE. (If anyone knows one, please let me know).
I then thought about replacing the raspberry pi with an android board, because android has support for BLE. But I wasn't able to find a board which is supported from android 5.1+ and offers support for BLE. Even the Odroid-boards don't seem to support android >4.4 and BLE.
Summary:
In general I liked the second and third option much better. It seemed to be the the more versatile, modern way. The first way felt a bit like a hack.
However I found those problems I presented above, and until now, I couldn't think of a way around it.
If anyone here:
1) Solved this problem already
2) Knows a really good, NON-HACKY, community supported, Java (BLE) Bluetooth library
3) Knows a language or framework which would be well suited to solve the problem
4) Has another good idea how to solve it
Please let me know!
I just want to build something sophisticated, (which I could maybe make an open source project out of it) which isn't hacky.
I mean, the problem has to be solvable, look at the Pebble smartwatch. They also solved it without android wear.
I really want to emphasise that this is an open question. I am not limited / fixed on Java, Raspberry pi or anything.
I those have two requirements.
1) I don't want to connect the smartphone to a cable, either for data or for power
2) The solution needs to be something power saving, so no hotspot on the android device
3) Non-hacky, sophisticated solution
Best regards
Me =)
PS: As English isn't my native language, I maybe put some sentences wrong or wasn't able to express something clearly and unambiguous.
Please feel free to ask, I'd be pleased to clear any questions!
Any updates?
Hi!
I know this is an old thread, but I'm struggling with a similar issue - except I want to use it for roadcycling. Did you have any luck with your project?
All the best
Marius
Hi.
I recently bought a couple of sonos speakers. I, as many others, am not impressed with the app they provide. Also, in many cases it is redundant. They now support spotify connect, but there is no plans for supporting the chromecast protocol. I would like to be able to cast anything from my phone, and just play whatever I'm casting on sonos. That way, I can more or less stop using their app and use casting instead, which is properly integrated in Android.
So... I have some ideas on how to accomplish this. Hence this thread. I list all three alternatives, feel free to suggest others I guess the only one really relevant to posting here is the first one. I have a 1st gen chromecast lying around. Although I haven't tried to root it, I'm guessing some smart folks here have done so. I also have a Nexus Player. And a raspberry pi... I am willing to buy a chromecast audio if that solves my problem.
1. Chromecast solution. Sonos does support radio URLs. I could create my own radio channel and broadcast whatever it is I'm streaming. This is most elegantly done by rooting a chromecast, and have it run a DLNA server. Is this possible? Preferably without spending months of time. First, I would to need run a DLNA server on the chromecast, I'm guessing that is doable. Second, I would need access to the audio stream. Either by having the DLNA server directly access the audio stream (if possible), or changing the audio output stream to a loopback and accessing it indirectly. Have anyone done this or similar before? Like running a DLNA server? Any hints? I should note that I'm fairly Linux-savvy. This is definitely technically possible, but is it a possible without spending enourmous amounts of time?
The rest of this post isn't really relevant to this forum, so feel free to skip it.
2. Raspberry pi solution. Buy a usb sound card with spdif in, connect a chromecast, and stream the input to my DLNA server. Fairly cheap solution, but seems excessive as the chromecast really is a computer, and should be able to do this by itself. Also, I might meet a wall with encoded audio streams. I could always go for a digital->analog->digital route though, but I'd rather go digital all the way.
3. Sonos solution. Buy a Sonos Play 5, which have optical input. This is definitely the best solution, but also very very expensive. I might be doing this in the long run.
Thanks for all tips!