• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Sending Images from PC to mobile

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am making an application which sends the PCs desktop screenshot to the mobile( NOKIA 6600) twice every second but i am encountering serious transfer rate issues. I have tried bringing down the size of the PC screenshot picture to 10KB but still the USB Dongle that i am using sends the picture in about two seconds time. Could anyone give me any suggestions as to reduce the transfer time.

Regards
Sal
 
author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me see if I understand the environment.
You have a cameraphone (nokia 6600), and you have a USB dongle that connects this phone to your desktop computer. Then you have an application (j2me) on the phone that pulls a picture, and sends it to the desktop computer.

So I am wondering what is the protocol you are using on the wire? (tcp,udp?)
what protocol are you using to transfer the information? (ftp, homegrown)
Is this a socket connection to the Desktop running some software?
Do you close the socket and reconnect each time you send a picture?

That may provide the clues needed to determine your issues, and then how to resolve them.

Regards
-Shawn
 
saad sal
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No not really Shawn.
I am making this Remote control for the desktop in which the mobile would act as a controller of the desktop. I need to display the Desktop screenshot on the mobile so that the user can see what he is controlling. The more pictures that i could send from the desktop in a second, the higher would be the refresh rate on the mobile.

So basically,

The desktop (server) application) (j2me) would send these pictures to the mobile phone (client application)(j2se).
I would be using UDP as the protocol.
Desktop is running a server.
i would not be opening and closing the socket. It would be one continous flow so that the data flow would not stop




Regards,
sal

[ August 01, 2005: Message edited by: saad sal ]
[ August 01, 2005: Message edited by: saad sal ]
 
Shawn Fitzgerald
author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You said there was a USB dongle? How is that involved? I mean if you are taking a screen shot and then tranmitting it view UDP over the cellular network where does USB come in?

So back to the more important question, time latency. The network connection over cellular, (GPRS) is not going to give you great response time. The promise of 3G is a little lacking. So you can take the network transmission speed that the marketing materials says, and divide it in half.

So a 144k 3G line really only gives you about 56k. And there are other features of GPRS, EDGE, CDMA, or IDEN that impact data transmission. So if you can compress, or better yet only transfer the diff of the previous image and the current image, that might help. However I would ever 5 or 10 frames update the whole page since you are using UDP. Also don't forget to put a counter so that you know if the frames get out of order.

In order of performance (lowest to highest bandwidth) you can assume:
Worst:
- IDen
- CDMA
- GPRS ~= RRTx1
- EDGE
Best:

Regards,
-Shawn
 
saad sal
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am sorry, I got confused there about the UDP.
I would be transferring the data through a USB Dongle using L2CAPs Packet-switched ACLs.( abt 128kbit/sec two-way), but i got it that what you said is quite similar and the only way that i can get images in quicker is by compressing them.

However I do want to know one thing, the data-rata that you told me. If i am not mistaken, it is 56kbit/sec (two-way) so hypothetically speaking that is only about 56/8= 7kBytes/sec. Would this data-rate be enough to send a picture file lets say a 10KB jpeg image, (before any compression or conversion using java).
Keeping in mind that i am using these pics once they arrive to the mobile to refresh the mobile screen.
So the problem is not only sending one picture file (screenshot of the desktop PC) but like 2 or 3 every second, so that the refresh rate on the mobile is higher.

And thankyou for your last answer. It helped me a lot.

Regards,
sal.
 
Shawn Fitzgerald
author
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well here is one of those times when being old helps. I don't need any fancy math to tell you 56kbit transfer rate is not fast enough to send multiple 10kB images per second. I remember having a 56k modem, and there was no way to have a decent size image 5-10kB download in less than a 1-2 seconds.
So really compression is the only way but there again you have to factor in the time to produce a diff on the server (desktop) side, and the time to translate the diff into the main image buffer on the client side (phone).
In theory as long as your diff of images were small between frames (which most likely will be the case) and the image size were not overly large you should be able to do it. One side note, how many colors do you support? 16, 256, 64k? The lower your color bit count the smaller your image. So if you can take the hit on color you might see about lower that to reduce your image size. get it below 5kB, and you might be able to get 1.5 images (before compression) and if your diffs are less than 1-2kB, then you could get 2 maybe 3 effective screen frames per second (negating processing time to do the diff).

Regards,
-Shawn
 
saad sal
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hey yeah, I was thinking along the same lines. I reduced the image quality by reducing the image pixels. Haven't tried decreasing the color bits but would do that too. On the mobile screen you cant really see the difference between a good quality image and a bad one because of the screen size. Moreover I have found out that the java package "java.util.zip.*" has a lot of functionalities that i would be able to use to compress the size further. Thanks for your help once again.

Regards,
sal
 
Look! It's Leonardo da Vinci! And he brought a tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic