Do anyone know is it possible to send video stream data though Seeed Cellular Radio ? and if possible how to do it?
Thanks in advance for your help
I do not believe that we have tested this in-house, however there is a driver available in CodeShare that allows TCP over this module.
https://www.ghielectronics.com/community/codeshare/entry/590
This will allow you to send raw data.
as far as i know that module uses serial to send data. i don’t think it will be able to stream video.
@ James - thanks, I will try this but can you tell me how to send stream on TCP ( sorry I’m not expert)
I would not go there. We are waiting someone to create a 3G cellular module where this would make sense.
Video stream is too much for a small embedded system.
Arduino playing video on a Nokia 3310 LCD
ATMega88 at 8 MHz playing video on a 240x64 LCD (this one’s really impressive!)
Never say never.
Those aren’t live video streams, nor are they being sent over Cellular TCP.
Video playback on GHI is possible via RLP (Hydra & 320x240):
Ironically enough the video on that page isn’t working 
If it can be done from SD (SPI mode) on an ATMega88 at 8MHz, then it can be done over cellular TCP (probably serial) on even the slowest Cortex-M0, assuming the serial link is fast enough.
In native code, there are a LOT of things possible even on the slowest systems that are totally out of the picture even for a very fast NETMF system.
NETMF needs a native compiler. AOT, JIT, whatever, it needs it. It’s sad to be shown up by an ATMega88 at 8MHz.
But how useful is that? You can barely see anything.
Genau – however I was reading more into his statement (live streaming).
[quote=“godefroi”]NETMF needs a native compiler. AOT, JIT, whatever, it needs it. It’s sad to be shown up by an ATMega88 at 8MHz.
[/quote]
Why do conversations always seem to devolve into these (pissing match) discussions?
[quote=“godefroi”]NETMF needs a native compiler. AOT, JIT, whatever, it needs it. It’s sad to be shown up by an ATMega88 at 8MHz.
[/quote]
I would agree on that one!
1 Like
I think this is interesting stuff. Does anyone know how optimized the Gadgeteer runtime system is? And how complex would it be to upgrade the core with some speed options.
I am experiencing the slowness on the Spider, and are still wondering.
Why do conversations always seem to devolve into these (pissing match) discussions?
[/quote]
This is not about pissing, its about experiencing serious issues in simple stuff like the music module that has problems on the Spider, and simple button presses that are missed because of timing and speed. I have struggled with many async threads and are still wondering where all these Mhz are spent.
1 Like
This is not about pissing, its about experiencing serious issues in simple stuff like the music module that has problems on the Spider, and simple button presses that are missed because of timing and speed. I have struggled with many async threads and are still wondering where all these Mhz are spent.
[/quote]
(in my vernacular a pissing match is simply a non-constructive discussion about why my side is better than yours)
Wondering about, discussing and (constructively) criticizing the framework makes sense on these forums.
But imo these constant conversations about why Arduino/Pi are better than the NETMF environment isn’t. Or the ones about how unnecessarily expensive NETMF hardware is.
Are things possible on NETMF that are not on Arduino - yes.
Are things possible on Arduino that are not on NETMF yes.
Are things possible on Pi that are not on NETMF yes.
Are Arduino barebones cheaper than NETMF, typically yes.
We all get that and accept that. No need to constantly compare the two or constantly point out where NETMF is lacking in one’s opinion.
Quite frankly I’m surprised that godefroi even uses NETMF based items seeing how poor they are in comparison to the platforms above and below it in costs.
Why are you so threatened when someone points out weaknesses in NETMF?
When Gus makes sweeping statements about embedded systems that are demonstrably false, I take issue with that. It’s not a pissing match, it’s critical thinking. Pretending NETMF is perfect won’t make it perfect. The only way we can improve it is to point out its weaknesses.
Obviously I’m not the only one that feels like NETMF could be improved.
I’m not threatened, I have no reason to be, I have not personal interest in any platform. I use other platforms as well. My preference for this platform is just that – my preference.
I don’t go on Arduino’s platform and (repeatedly) compare it to the NETMF/Pi platforms.
I’m just annoyed at the repetitive non-constructive criticisms that are injected due to personal bias.
In thread for example — instead of just showing that it can be done on an Arduino, this snarky comment was thrown in.
We all feel that NETMF can be improved - but we all don’t constantly point out how it compares to other platforms.
Based on your repeated (that’s theme here) comments about performance, capability and cost comparisons, I still don’t know why you use the NETMF platform.
**
I’m sorry for taking this off topic, and I’ll refrain from doing so further.
1 Like
Back on topic, then, video on that level should be quite possible, on something like Cerb/G120/Raptor/Hydra, over the cellular module, assuming the link is of sufficient speed.
Even in managed code.
You’re not going to get high-resolution color video at any reasonable framerate, of course, but that’s more likely to be a limitation of the link speed than it is to be a limitation of the processor. Given CPU limitations, you’re not going to be able to do any very complex compression scheme.
1 Like
That’s another unknown in the earlier shown “what’s possible” videos. The compression and optimization has most likely all been done prior to the content being displayed, so they’re dealing with the minimum number of bytes to start with. Trying to make a generic camera and device work with live video will be challenging, and you’re really going to need to have a set of devices that you can optimize separately, like reducing the image size and leveraging more compression at the camera level to likewise reduce the input data volume…