模拟 GPS 或串行设备

发布于 2024-08-09 14:45:33 字数 649 浏览 11 评论 0 原文

是否可以从 Google Gears 获取位置数据,Google Gelocation API 或任何其他网络位置 API(例如 Fire Eagle) 的格式是否会在其他软件中显示为 GPS 设备?

我在超级用户上阅读关于 WiFi 位置查找问题的这些答案,发现如果我可以模拟一个 GPS 单元,那么许多网络服务就可以充当“穷人”的 GPS,以供其他需要它的不太有用的软件使用。

GPSD 是一个选项吗?

最好是 OSX 和Python,但我对任何实现都感兴趣。

Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?

It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.

Is GPSD an option?

Preferably OSX & Python, but I would be interested in any implementation.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

明明#如月 2024-08-16 14:45:33

有一个非常相似的线程 Python 邮件列表,其中提到了 Windows 虚拟 COM 端口 并讨论了 Unix 的伪 tty 功能。如果您要使用的应用程序允许您输入特定的 tty 设备文件,这可能是最简单的途径。 (没有要求作者为你想要做的事情提供一个插件 API,或者给自己购买一个 20 美元的蓝牙 GPS 鼠标。)

您使用的是 OS X 吗?

Google 代码上有一个 macosxvirtualserialport 项目,它提供了围绕某些功能的图形包装器一个名为 socat 的实用程序。如果您看到伪 tty 路线的潜力,我建议您看看 socat。我相信您可以使用 socat 将管道从 Python 程序链接到伪 tty。

大多数本机 Mac 应用程序将查询 IOServiceMatching 以查找具有 kIOSerialBSDRS232Type 的设备,并且我怀疑伪 tty 是否会显示为 IOKit 服务。

在这种情况下,除非您能找到一个已经实现了此类功能的项目,否则您将需要实现一个驱动程序,如如何创建虚拟COM端口线程。如果您要麻烦地创建一个设备驱动程序,您可能会希望将其基于 IOKit,因为可能存在 IOServiceMatching 查询。您可以在 Apple 开源项目的顶部找到该文章中提到的 Apple16X50Serial 项目代码列表(如果您想要定位某些内容,请转到主页并选择较旧的操作系统版本10.6 之前的版本)。

如果您的应用程序对实时数据最有用(例如,Python 邮件列表主题中提到的 RouteBuddy 应用程序 可以记录当前位置),那么您将需要从网络源获取更新(希望它们支持长轮询)并将其转换为基本的NMEA RMC 语句。您不想从驱动程序代码内部执行此操作。相反,将您的工作划分为可以通信的内核态和用户态部分,并将尽可能少的代码放入内核部分。

如果您想让应用程序读取和写入这些 Web 服务,最好的选择可能是模拟 Garmin 设备。 Garmin 在 设备接口 SDK。同样,您希望将尽可能多的代码拆分为用户空间代码。

我无法找到一个项目或实用程序来实现基于 IOKit 的虚拟串行接口的内核端,但如果没有一个项目或实用程序隐藏在那里,我会感到惊讶。不幸的是,我发现这个问题的大多数答案都是这样的,开发人员被告知要忙起来编写 kext

There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)

Are you using OS X?

There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.

Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.

In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).

If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.

If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.

I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.

祁梦 2024-08-16 14:45:33

我不太确定如何完成您所要求的任务,但我也许可以提供一些关于您如何开始完成任务的见解。所以这里是这样的:

GPS 设备对大多数系统来说只不过是一个串行设备——如果您使用的是 Windows,则称为 COM 端口;如果您使用的是 *nix,则称为 /dev/ttySx。根据定义,串行端口的具体职责是通过总线传输数据,一次一个数据块。因此,从逻辑上讲,如果您想模拟 GPS 设备的存在,您应该收集您正在使用的数据并将其放入一个流中,该流以某种方式充当活动串行端口。

然而,您可能需要考虑一些复杂情况:

  • 大多数 GPS 设备不仅发送位置数据,还发送位置数据。还有有关卫星位置、定位质量、方位等的信息。话又说回来,没有人制定任何规则说您必须提供所有数据。可能还有更多内容,但我承认我自己需要在这个领域进行更多研究。
  • 我不确定在处理谷歌纵横等时您接收数据的速度有多快,但是接收中的任何延迟肯定会导致“串行端口”数据流中出现明显的暂停。再说一次,这可能并不像看起来那么复杂,因为众所周知,GPS 设备无论如何都会在总线上“爆发”数据,但我肯定会密切关注这一点。您需要确保始终存在数据过剩,而不是短缺。

在此过程中,您还必须将收到的坐标转换为有效的 GPS 语句。您可以找到这些规范,但我肯定会与 NMEA 标准交朋友——尽管它是一个有缺陷的标准,但无论如何,它似乎是每个人都同意的标准。

希望这对您有帮助,至少是一点点。您认为还有更多针对您的问题的详细信息对回答此问题有用吗?

I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:

A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.

There are, however, some complications you might want to consider:

  • Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
  • I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.

Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.

Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?

紫南 2024-08-16 14:45:33

查看 Franson GPS Gate,它可以让您连接Google Earth 等(例如模拟 GPS 等)。虽然只是Windows,但我认为你可以从中得到一些有用的想法。

Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.

暮色兮凉城 2024-08-16 14:45:33

我没有深入研究过,但是您考虑过使用 Skyhook 的 SDK 吗?它可能会为您提供一些您正在寻找的东西。它适用于所有主要桌面和移动操作系统。

I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文