I bought a laptop in 2005; It was towards the high end of what retailers carried in stores at the time, although it was on clearance, making way for the Windows Vista machines that replaced it, and I got an employee discount on the display model. It was a good deal.
It had a 15.4 inch screen at 1280x800 resolution.
Since then, Apple came out with the Retina Displays on their mobile devices, and has shuffled in an era of pushing their 27 inch displays with 2560x1440 resolution for some time now.
One would then assume that a laptop built in 2012 would be boasting improved resolution in both dimensions... Yet my fairly high end Toshiba is shamefully left behind with 1366x768 resolution. What gives?
See, Apple is pushing the pixel density envelope, so to speak, but the rest of the industry is stuck following some TV standards game like they've realized consumers don't WANT a computer, consumers want a TV that they can browse the internet with...
I watched it happen while I was working at a major office supply store: The marketing material on these laptops started changing to claim that these laptops supported "Full HD" resolutions... Which were oddly lower resolution than the laptops they were replacing... Yet, consumers flocked to them, like they were somehow better; Apparently the ability to watch Bluray at it's native resolution has gotten everyone so happy in their pants that higher resolutions don't even occur to them. Good job consumers, you have successfully turned your laptops into very powerful televisions. And how many of you actually have bluray players that can use those "Full HD" displays? Well, let's just say that my expensive high end laptop didn't make the "Contains a bluray player" cut.
Recently Toshiba announced the pending release of their new line of "4K HD" laptop displays... The price of which are unknown, but "Expensive" seems to be a safe guess. You can read about them here: http://betanews.com/2014/01/06/toshiba-unveils-first-ever-4k-laptops-but-do-consumers-actually-need-them/
Does content exist at that resolution? No... Does a laptop user need that aspect ratio? No. Even if they COULD use it, could one even see pixels that small on a 15 inch screen? I would argue nay.
Do *I* need a 4K resolution display? No, never... But do I want it, because it's the only way I can break this "Full HD" artificial limit on screen resolution? Well, I guess I don't have an overabundance of choice, do I?
Monday, January 6, 2014
Friday, December 6, 2013
Thoughts on servers, virtualization, Linux and BSD
I've been studying for my RHCSA/RHCE exam; While I have been reading a book on the subject, the primary study technique has been to build a full server at the house, featuring all the software that needs to be configured on the practical exam. I should be VERY ready when I finally walk in to take the exam, probably early next month.
Of course, it hasn't always gone smoothly... I initially built it in VMs on Citrix XenServer, but because each environment needed dedicated system resources, I ran out of RAM rather quickly. Next, I tried putting everything on one install, which seemed to be working alright until I turned on the router/firewall... Then everything inside the network, and everything outside the network worked... But aside from the firewall itself, nothing running on the server was accessible anywhere... I could probably fix it somehow, but from a security perspective, having it set up that way was still wrong.
I am now rebuilding the entire server system on three Linux Containers. Although, before a few days ago, I had never heard of them, so I've been researching them, and eventually on comparisons between them and FreeBSD jails. See, I had been operating on the belief that NetBSD was the Most Secure Operating System Ever™, and FreeBSD, it's close cousin, and it's Jails, MUST be similarly secure; I wondered how Linux Containers compared to that Holy standard.
In this vein, I found this blog post: http://aboutthebsds.wordpress.com/2013/01/13/freebsd-jails-are-a-huge-security-danger/. I was confused by it; How had I come to be so far off base? It occurs to me that IF FreeBSD jails were as good as they claim, then how the hell did the people that broke out of those jails on iOS actually do it? Maybe there's a thread of truth in that post.
I'm still a bit skeptical; I mean, this is a Linux guy bashing BSD... No one is surprised by this. Still, it appears to be well researched... This guy MIGHT know what he's talking about. I have read a lot on the blog now, the latest being this post: http://aboutthebsds.wordpress.com/2013/03/31/bsd-vs-linux/. All of the points make a lot of sense... At least logically. And it REALLY paints a terrifying picture of BSD.
Of course, I'm a Linux guy, so why do I even care about BSD at all? Well, one thing was FreeBSD Jails... But, apparently, they aren't what I ACTUALLY want. Another thing is ZFS; But even while I was writing this post, I was reading this article: http://www.eall.com.br/blog/?p=2481, and that has me rethinking that plan too... I'll have to read more on THAT subject as well.
So I'm building my servers on Linux Containers and (Where necessary), in Linux Kernel-mode Virtual Machines. Hopefully this will give me some reliability against my former problems, and maybe some security bonuses as well!
Of course, it hasn't always gone smoothly... I initially built it in VMs on Citrix XenServer, but because each environment needed dedicated system resources, I ran out of RAM rather quickly. Next, I tried putting everything on one install, which seemed to be working alright until I turned on the router/firewall... Then everything inside the network, and everything outside the network worked... But aside from the firewall itself, nothing running on the server was accessible anywhere... I could probably fix it somehow, but from a security perspective, having it set up that way was still wrong.
I am now rebuilding the entire server system on three Linux Containers. Although, before a few days ago, I had never heard of them, so I've been researching them, and eventually on comparisons between them and FreeBSD jails. See, I had been operating on the belief that NetBSD was the Most Secure Operating System Ever™, and FreeBSD, it's close cousin, and it's Jails, MUST be similarly secure; I wondered how Linux Containers compared to that Holy standard.
In this vein, I found this blog post: http://aboutthebsds.wordpress.com/2013/01/13/freebsd-jails-are-a-huge-security-danger/. I was confused by it; How had I come to be so far off base? It occurs to me that IF FreeBSD jails were as good as they claim, then how the hell did the people that broke out of those jails on iOS actually do it? Maybe there's a thread of truth in that post.
I'm still a bit skeptical; I mean, this is a Linux guy bashing BSD... No one is surprised by this. Still, it appears to be well researched... This guy MIGHT know what he's talking about. I have read a lot on the blog now, the latest being this post: http://aboutthebsds.wordpress.com/2013/03/31/bsd-vs-linux/. All of the points make a lot of sense... At least logically. And it REALLY paints a terrifying picture of BSD.
Of course, I'm a Linux guy, so why do I even care about BSD at all? Well, one thing was FreeBSD Jails... But, apparently, they aren't what I ACTUALLY want. Another thing is ZFS; But even while I was writing this post, I was reading this article: http://www.eall.com.br/blog/?p=2481, and that has me rethinking that plan too... I'll have to read more on THAT subject as well.
So I'm building my servers on Linux Containers and (Where necessary), in Linux Kernel-mode Virtual Machines. Hopefully this will give me some reliability against my former problems, and maybe some security bonuses as well!
Saturday, October 5, 2013
Why am I thinking so much about Digital Voice modes?
I have a project I would like to do... I want to be able to remotely lock/unlock my car, remotely start the car in the morning, and to be notified remotely if the alarm is going off. Some commercial products do some of those things; Certainly, the locking, unlocking, and remote starting are easy... As long as I'm in range of a key fob transmitter. In the modern era, even the rest of it is doable, given cell phone technologies (See the Chevy commercials that allow you to do all of that from your smartphone.) But what if the car is outside of my office building, and I'm working on the far side and can't hear the alarm? Or if I'm in a building that doesn't have cell service? Or if I'm at the mall, and I want the car warm when I get there?
Ham radio transmitters have more power than the keyfobs, and would probably solve some of these problems; Ham radio repeaters often have better coverage than cell towers, and would also largely solve the problem; The APRS network, as one example, has entirely decent national coverage, and can relay messages across RF and the internet to get a message across the country. Clearly, to get what I want, I need something from the amateur market.
SO, a couple of years ago, I started researching various digital modes for this purpose... POCSAG was nice, as it can provide the telecommand services I need... However, it's one directional, and the car wouldn't be able to report back it's success on a command, or tell me of a problem. APRS is bi-directional, and supports telemetry and text messages... I could build an interpretter that could use text messages as commands... But it's certainly not very battery efficient... Maybe a combination of the two: POCSAG for telecommand, APRS for telemetry... Keep the pager on all the time, but the APRS only boots up in the case of an event.
But then the idea of D-STAR occurred to me... It's getting good press, it supports voice and text messages, and it is designed for amateur radio; It's neat, because it carries your callsign as the radio ID, and can do call routing based on your callsign. However, through research, I found that the equipment isn't very well built, as Icom doesn't have any competition in the market... And the spec is poorly written, with the FEC in the datastream, NOT the voice stream, perpetuating lost packets and slow resync on the fringe of each repeater's coverage.
ETSI DMR, and particularly MotoTRBO, seemed to solve those design failures, and was just downright awesome, with 2-timeslot TDMA, and built in telemtry and telecommand. The only downside was the lack of datastream callsign radio IDs... Leading to some questionable legal issues in my project.
Also, in all cases, the price is absurd. I can't afford it, none of my friends can afford it, and to make my project work, I would need to buy TWO radios just to have no one to talk to...
Yet, I am following all of these forums about D-STAR, D-STAR GMSK Nodes, MotoTRBO, DMR-MARC, etc. I could BUY a MotoTRBO radio, add a GMSK node, and have DMR, D-STAR, and analog all in one radio, all for less than the cost of one of each! But... I still wouldn't have anyone to talk to... And it would be rediculous overkill for my car project.
The fact of the matter is that I can't afford any of those radios... None of my friends can, either... And if I can't talk to my friends, I'm just not interested. Further, if I can't use them in the back country, when I'm stuck in the snow and need a recovery, then it's pretty much useless.
My emotional mind is super curious and wants to build a D-STAR gateway at home... But my logical mind tells me that doing so would be a waste of time and money. I want to be on the cutting edge, but in the real world, I just need what works... At at this moment, FM voice is what works.
As for my car project... It will stay on the back burner for a while... And if I ever get around to doing it, the POCSAG telecommand / APRS telemetry idea is probably my best bet. I just wish I could get myself to emotionally calm down about this digital voice stuff...
Ham radio transmitters have more power than the keyfobs, and would probably solve some of these problems; Ham radio repeaters often have better coverage than cell towers, and would also largely solve the problem; The APRS network, as one example, has entirely decent national coverage, and can relay messages across RF and the internet to get a message across the country. Clearly, to get what I want, I need something from the amateur market.
SO, a couple of years ago, I started researching various digital modes for this purpose... POCSAG was nice, as it can provide the telecommand services I need... However, it's one directional, and the car wouldn't be able to report back it's success on a command, or tell me of a problem. APRS is bi-directional, and supports telemetry and text messages... I could build an interpretter that could use text messages as commands... But it's certainly not very battery efficient... Maybe a combination of the two: POCSAG for telecommand, APRS for telemetry... Keep the pager on all the time, but the APRS only boots up in the case of an event.
But then the idea of D-STAR occurred to me... It's getting good press, it supports voice and text messages, and it is designed for amateur radio; It's neat, because it carries your callsign as the radio ID, and can do call routing based on your callsign. However, through research, I found that the equipment isn't very well built, as Icom doesn't have any competition in the market... And the spec is poorly written, with the FEC in the datastream, NOT the voice stream, perpetuating lost packets and slow resync on the fringe of each repeater's coverage.
ETSI DMR, and particularly MotoTRBO, seemed to solve those design failures, and was just downright awesome, with 2-timeslot TDMA, and built in telemtry and telecommand. The only downside was the lack of datastream callsign radio IDs... Leading to some questionable legal issues in my project.
Also, in all cases, the price is absurd. I can't afford it, none of my friends can afford it, and to make my project work, I would need to buy TWO radios just to have no one to talk to...
Yet, I am following all of these forums about D-STAR, D-STAR GMSK Nodes, MotoTRBO, DMR-MARC, etc. I could BUY a MotoTRBO radio, add a GMSK node, and have DMR, D-STAR, and analog all in one radio, all for less than the cost of one of each! But... I still wouldn't have anyone to talk to... And it would be rediculous overkill for my car project.
The fact of the matter is that I can't afford any of those radios... None of my friends can, either... And if I can't talk to my friends, I'm just not interested. Further, if I can't use them in the back country, when I'm stuck in the snow and need a recovery, then it's pretty much useless.
My emotional mind is super curious and wants to build a D-STAR gateway at home... But my logical mind tells me that doing so would be a waste of time and money. I want to be on the cutting edge, but in the real world, I just need what works... At at this moment, FM voice is what works.
As for my car project... It will stay on the back burner for a while... And if I ever get around to doing it, the POCSAG telecommand / APRS telemetry idea is probably my best bet. I just wish I could get myself to emotionally calm down about this digital voice stuff...
Tuesday, October 1, 2013
NMEA Sentences, Kenwood Sentences, and the G6APRS
This afternoon, Don Arnold (W6GPS) wrote on the G6APRS forums on Yahoo a rather informative post about how support for the full set of APRS icons and such are supported inside the AvMap G6APRS:
On Tue, Oct 1, 2013 at 10:15 AM, <w6gps@yahoo.com> wrote:
In response, I felt it was important to make the following technical response:
I have noticed two things that happen on this list far too frequently: 1) Fancy terms like "NMEA," "Sentence," and "PKWDWPL" or "$GPWPL" get thrown around without any explanation, and 2) The assumption that the audience is a bunch of industry experts is made rather falsely. Let me do my best to break down these terms for the benefit of the general public, who might not know the difference between a "Computer," a "Hard drive," and the "Screen."
The National Marine Electronics Association (NMEA) wrote a bunch of communication standards back in the '80s to specify how navigation equipment, weather instruments, mechanical and electrical sensors, autopilot, and other boat electronics communicate together; This standard was called NMEA 0183. Think of NMEA 0183 as the boating world's version of the onboard computer in your car, except that it's expandable and is supported by a bunch of different manufacturers. Remember that by 1993, when GPS first became available to the public, NMEA was already an established standard; The data we are trying to use today was not forseen by it's developers.
On the wire, NMEA 0183 uses RS-422, which is electrically similar to but not quite the same as the serial port on your computer (RS-232); It sends pulses of 1's and 0's using ASCII characters. Radio people will understand it, as it's not entirely unlike the over-the-air standards used in our digital modes. SO, these 1's and 0's form words and sentences, much like written language; So when we say "Sentence," we mean literally a sentence with words of data.
I've been researching this NMEA sentence stuff for some time now (The last two years, anyway). Each sentence starts with a $, a data type, and then the information carried by that data type, and ends with an *, a check sum and a carriage return. GPS data starts with $GP, and is followed by a wide range of specific datatypes; Of interest to this group might be the $GPWPL sentence, which carries a waypoint to be displayed; It carries only a name and a location, and sometimes whether or not the waypoint is moving. TECHNICALLY, our use of $GPWPL is wrong... The dreaded breadcrumb trail that some older Garmins are famous for is actually the CORRECT behavior, as each one of the $GPWPL lines is supposed to be displayed as a NEW waypoint... It's intended as a method of distributing a waypoint between multiple chartplotters on a boat.
So far in my research, I have been refusing to even look at the official spec, because to do so might compromise some future projects I may work on; and have been looking at the reverse engineered spec instead. Let's just say that it's a mess... For some interesting reading on the subject, check out this: http://esr.ibiblio.org/?p=801.
The reason I mention it is this: The NMEA sentences are incomplete, even in carrying just GPS location data... The data spit out by a standard GPS may or may not carry elevation, or error rate, or any other combination of important data. Many manufacturers use custom fields (Identified with a $P, followed by a three digit manufacturer code, followed by 2-5 digit data type code; In the case of Kenwood, this is a $PKWDWPL for the Kenwood custom waypoint sentence) that fix these oversights in the spec. Unlike the $GPWPL sentence mentioned before, the $PKWDWPL sentence is designed to specify a temporary waypoint, one that gets deleted when the next waypoint from that callsign gets sent. It's pretty neat... As it's designed by radio engineers for the purpose of supporting APRS, rather than boat engineers with the purpose of communicating with boat navigation equipment. Just a few thoughts on the Kenwood sentence... It is called such because it's a Proprietary Sentence from Kenwood (From NMEA's perspective), not because Kenwood is protecting it; As Don has mentioned, several other manufacturers support it, and it's fairly well documented when you know what to look for.
The reason I've been researching this stuff is this: GPSd is the daemon responsible for interpreting GPS data on Linux, and by extension, Android; It's capable of spitting out NMEA sentences, and also a more complete sentence developed by them for use with software based on their libraries; Because their sentence fills in the gaps left in other GPS manufacturer's implementations, it's output can be used more reliably than the input data. It's pretty cool...
Also interesting are the Automatic Information System (AIS) sentences, which are designed to carry data similar to APRS but engineered for boats (Boat identifier, boat name, length, bearing, destination, size, etc.). The advantage being that AIS is standardized by NMEA, and is supported by a wide array of chartplotters and GPS units; The disadvantage is that AIS's icon set only includes boats... Far from complete for APRS use. However, being similar to APRS, it also carries a lot of the data we care about; Namely, the identifier, name, and velocity; However, because all boats are at sea level, it does NOT carry elevation.
Finally, I dream of someday writing a library that converts between the AIS sentences and the Kenwood sentences, the hope being that I can use a amateur radio TNC, paired with am AIS Chartplotter, and display APRS data in a more complete form than the $GPWPL sentence currently allows.
I also dream of a day when I can use ONE G6 with TWO TNCs and radios, and be able to participate in both VHF APRS and UHF high speed APRS simultaneously... It SHOULD be as easy as plugging in a multiplexer, but I can't afford one... So maybe with this software I want to write, I will be able to use a Raspberry Pi as a cheap multiplexer.
I hope that this post gives some insight into how this stuff works, and when Don throws around these terms, people can better understand what he's talking about; And should any of my dream projects come to fruition, this may be a good reference for what it's all about as well ;)
--
EDIT: It has been brought to my attention that this post may come off in a derogetory tone; It's the furthest thing from my intention to offend anyone. Specifically, with regard to my comment "who might not know the difference between a 'Computer,' a 'Hard drive,' and the 'Screen.'"I didn't mean it as a put down, and I'm sorry if it came off that way... In fact, I meant the exact opposite; Allow me to explain:
I only use that example because 1) most of my readers WILL know those differences, and might understand how others might not... And 2) it describes many of the people in my life... Including my own parents, who are professionals in their own fields, and know a great deal more about the law and real estate than I ever will (My mom is a lawyer, and my father is a real estate developer). Further, I'm a Geography major, and some of my college age classmates are unaware of the technical aspects of what a computer is, despite using them on a daily basis; That said, they probably know more about things like map projections, slip faults, and tree rings than most IT professionals do. Just because you aren't an expert in all fields doesn't mean your not an expert in something... And it certainly doesn't mean that your an idiot.
All I'm saying is that, in all things, it's important to assess your audience. And on a mailing list that targets radio experts, throwing around technical developer nautical terms might not be the best path to a conducive learning environment.
On Tue, Oct 1, 2013 at 10:15 AM, <w6gps@yahoo.com> wrote:
this is clearly Yeasu. The Kenwood sentence is not proprietary. Argent and Byonics use it and they have not been sued. I guess the Idea of Yeasu having a function call Kenwood sentence in there radio is not cool..but any way if Yeasu created a P YEAD wpl instead of P KWD wpl and if parsed the same Avmap could also add the process this prompt command to the string and you would get all these features..
now using Magellan or Garmin format selection does not create a conflict. But to have the word Kenwood as a menu Item in a Yeasu radio I think wont happen...call it APRS Format with a PKWDWPL command prompt
and the Avmap will reconize the command then parse the string out correctly..But as far as I can see I cannot even get the wpl sentence out of the FTM400. Don
---In G6APRS@yahoogroups.com, <g6aprs@yahoogroups.com> wrote:
So who's to blame here? Is it Yaesu's fault for not
implementing/supporting the Kenwood proprietary sentence format. Or is
this a case where it's "proprietary" and therefore Yaesu can't
implement or support it even if they wanted to?
New to the group (first post!), so sorry if this has been explained before.
Thanks!
-- Daniel - KJ4DAJ
In response, I felt it was important to make the following technical response:
I have noticed two things that happen on this list far too frequently: 1) Fancy terms like "NMEA," "Sentence," and "PKWDWPL" or "$GPWPL" get thrown around without any explanation, and 2) The assumption that the audience is a bunch of industry experts is made rather falsely. Let me do my best to break down these terms for the benefit of the general public, who might not know the difference between a "Computer," a "Hard drive," and the "Screen."
The National Marine Electronics Association (NMEA) wrote a bunch of communication standards back in the '80s to specify how navigation equipment, weather instruments, mechanical and electrical sensors, autopilot, and other boat electronics communicate together; This standard was called NMEA 0183. Think of NMEA 0183 as the boating world's version of the onboard computer in your car, except that it's expandable and is supported by a bunch of different manufacturers. Remember that by 1993, when GPS first became available to the public, NMEA was already an established standard; The data we are trying to use today was not forseen by it's developers.
On the wire, NMEA 0183 uses RS-422, which is electrically similar to but not quite the same as the serial port on your computer (RS-232); It sends pulses of 1's and 0's using ASCII characters. Radio people will understand it, as it's not entirely unlike the over-the-air standards used in our digital modes. SO, these 1's and 0's form words and sentences, much like written language; So when we say "Sentence," we mean literally a sentence with words of data.
I've been researching this NMEA sentence stuff for some time now (The last two years, anyway). Each sentence starts with a $, a data type, and then the information carried by that data type, and ends with an *, a check sum and a carriage return. GPS data starts with $GP, and is followed by a wide range of specific datatypes; Of interest to this group might be the $GPWPL sentence, which carries a waypoint to be displayed; It carries only a name and a location, and sometimes whether or not the waypoint is moving. TECHNICALLY, our use of $GPWPL is wrong... The dreaded breadcrumb trail that some older Garmins are famous for is actually the CORRECT behavior, as each one of the $GPWPL lines is supposed to be displayed as a NEW waypoint... It's intended as a method of distributing a waypoint between multiple chartplotters on a boat.
So far in my research, I have been refusing to even look at the official spec, because to do so might compromise some future projects I may work on; and have been looking at the reverse engineered spec instead. Let's just say that it's a mess... For some interesting reading on the subject, check out this: http://esr.ibiblio.org/?p=801.
The reason I mention it is this: The NMEA sentences are incomplete, even in carrying just GPS location data... The data spit out by a standard GPS may or may not carry elevation, or error rate, or any other combination of important data. Many manufacturers use custom fields (Identified with a $P, followed by a three digit manufacturer code, followed by 2-5 digit data type code; In the case of Kenwood, this is a $PKWDWPL for the Kenwood custom waypoint sentence) that fix these oversights in the spec. Unlike the $GPWPL sentence mentioned before, the $PKWDWPL sentence is designed to specify a temporary waypoint, one that gets deleted when the next waypoint from that callsign gets sent. It's pretty neat... As it's designed by radio engineers for the purpose of supporting APRS, rather than boat engineers with the purpose of communicating with boat navigation equipment. Just a few thoughts on the Kenwood sentence... It is called such because it's a Proprietary Sentence from Kenwood (From NMEA's perspective), not because Kenwood is protecting it; As Don has mentioned, several other manufacturers support it, and it's fairly well documented when you know what to look for.
The reason I've been researching this stuff is this: GPSd is the daemon responsible for interpreting GPS data on Linux, and by extension, Android; It's capable of spitting out NMEA sentences, and also a more complete sentence developed by them for use with software based on their libraries; Because their sentence fills in the gaps left in other GPS manufacturer's implementations, it's output can be used more reliably than the input data. It's pretty cool...
Also interesting are the Automatic Information System (AIS) sentences, which are designed to carry data similar to APRS but engineered for boats (Boat identifier, boat name, length, bearing, destination, size, etc.). The advantage being that AIS is standardized by NMEA, and is supported by a wide array of chartplotters and GPS units; The disadvantage is that AIS's icon set only includes boats... Far from complete for APRS use. However, being similar to APRS, it also carries a lot of the data we care about; Namely, the identifier, name, and velocity; However, because all boats are at sea level, it does NOT carry elevation.
Finally, I dream of someday writing a library that converts between the AIS sentences and the Kenwood sentences, the hope being that I can use a amateur radio TNC, paired with am AIS Chartplotter, and display APRS data in a more complete form than the $GPWPL sentence currently allows.
I also dream of a day when I can use ONE G6 with TWO TNCs and radios, and be able to participate in both VHF APRS and UHF high speed APRS simultaneously... It SHOULD be as easy as plugging in a multiplexer, but I can't afford one... So maybe with this software I want to write, I will be able to use a Raspberry Pi as a cheap multiplexer.
I hope that this post gives some insight into how this stuff works, and when Don throws around these terms, people can better understand what he's talking about; And should any of my dream projects come to fruition, this may be a good reference for what it's all about as well ;)
--
EDIT: It has been brought to my attention that this post may come off in a derogetory tone; It's the furthest thing from my intention to offend anyone. Specifically, with regard to my comment "who might not know the difference between a 'Computer,' a 'Hard drive,' and the 'Screen.'"I didn't mean it as a put down, and I'm sorry if it came off that way... In fact, I meant the exact opposite; Allow me to explain:
I only use that example because 1) most of my readers WILL know those differences, and might understand how others might not... And 2) it describes many of the people in my life... Including my own parents, who are professionals in their own fields, and know a great deal more about the law and real estate than I ever will (My mom is a lawyer, and my father is a real estate developer). Further, I'm a Geography major, and some of my college age classmates are unaware of the technical aspects of what a computer is, despite using them on a daily basis; That said, they probably know more about things like map projections, slip faults, and tree rings than most IT professionals do. Just because you aren't an expert in all fields doesn't mean your not an expert in something... And it certainly doesn't mean that your an idiot.
All I'm saying is that, in all things, it's important to assess your audience. And on a mailing list that targets radio experts, throwing around technical developer nautical terms might not be the best path to a conducive learning environment.
Monday, September 2, 2013
Kenwood TM-D710 vs. Yaesu FT-8800
In preparation of moving from Reno, NV to Portland, OR, and in anticipation of my friend getting his ham radio license after the move, I installed ham radios in both his Mazda Tribute, and my wife's Jeep Grand Cherokee... The hope was that we would be able to use MURS frequencies to communicate between the two cars and the moving truck as we drove up...
Unfortunately, we weren't able to get our hands on the antennas before we left Reno... ON the plus side, we didn't have to illegally use MURS frequencies without type-approved radios... On the downside, the drive was WAY more sketchy than I would have liked :/
BUT, with a Ham Radio Outlet in town, we were finally able to finish both radio installs after the move... And I have programmed two different club's repeaters into the radios. It's exciting... I really love having the radio equipment properly installed in my daily driver again ;)
--
And I'm just going to throw it out there: Every time I have to mess with the Kenwood TM-D710, I fall more in love with it... It has a truly amazing feature set, everything from the built in APRS, to the selectable display color, to the fact that the display shows BOTH the frequency and the memory name AT THE SAME TIME... It's very much the best radio I have ever used.
While I got this radio for it's APRS functionality, I'm not using anymore; We have a Byonics TinyTrak4 and a Motorola Maxtrac serving those needs now. Portland has a lot of UHF high-speed APRS activity... I may get an NMEA multiplexer to run my AvMap G6 on both VHF through the TT4 and UHF through the TM-D710 at some point in the future... But for the moment, I kinda like having both sides of the radio available for voice.
--
By comparison, my friend's Yaesu FT-8800 is a feature-rich radio, and is considerably cheaper... Especially at the FANTASTIC price he got his for. It lacks the APRS, but I don't think I miss it; I prefer the wider feature set of the TT4, and not losing one of the receivers to that use; We will eventually get our hands on another Maxtrac and a TT4 for him. I'm also liking that it can demodulate AM, which is fun for monitoring the airport approach frequency.
But it has a separate memory bank for the left and right side receivers... Which is kinda weird. Also, like most ham radios, you have to chose between the frequency or the memory name. I'll use the memory names I used on my Wouxun to solve the problem (Last three digits of the frequency, with the first three letters of the location name), but it's really not as convenient.
I also don't like that I have no choice but to use both receivers; The TM-D710 allows you to disable one side or the other, which is REALLY nice. As it is, I just turned down the volume on the right side, and set the controls to the left... But it clutters the screen, and uses slightly more power, all for no gain in his current use case.
--
I really love my TM-D710... When it comes time to load MY jeep with a radio, I'm defiantly going to get another Kenwood. I'll probably skip over the D710, and drop down to the TM-V71... But it's a much better radio, and I don't mind spending the extra money.
Unfortunately, we weren't able to get our hands on the antennas before we left Reno... ON the plus side, we didn't have to illegally use MURS frequencies without type-approved radios... On the downside, the drive was WAY more sketchy than I would have liked :/
BUT, with a Ham Radio Outlet in town, we were finally able to finish both radio installs after the move... And I have programmed two different club's repeaters into the radios. It's exciting... I really love having the radio equipment properly installed in my daily driver again ;)
--
And I'm just going to throw it out there: Every time I have to mess with the Kenwood TM-D710, I fall more in love with it... It has a truly amazing feature set, everything from the built in APRS, to the selectable display color, to the fact that the display shows BOTH the frequency and the memory name AT THE SAME TIME... It's very much the best radio I have ever used.
While I got this radio for it's APRS functionality, I'm not using anymore; We have a Byonics TinyTrak4 and a Motorola Maxtrac serving those needs now. Portland has a lot of UHF high-speed APRS activity... I may get an NMEA multiplexer to run my AvMap G6 on both VHF through the TT4 and UHF through the TM-D710 at some point in the future... But for the moment, I kinda like having both sides of the radio available for voice.
--
By comparison, my friend's Yaesu FT-8800 is a feature-rich radio, and is considerably cheaper... Especially at the FANTASTIC price he got his for. It lacks the APRS, but I don't think I miss it; I prefer the wider feature set of the TT4, and not losing one of the receivers to that use; We will eventually get our hands on another Maxtrac and a TT4 for him. I'm also liking that it can demodulate AM, which is fun for monitoring the airport approach frequency.
But it has a separate memory bank for the left and right side receivers... Which is kinda weird. Also, like most ham radios, you have to chose between the frequency or the memory name. I'll use the memory names I used on my Wouxun to solve the problem (Last three digits of the frequency, with the first three letters of the location name), but it's really not as convenient.
I also don't like that I have no choice but to use both receivers; The TM-D710 allows you to disable one side or the other, which is REALLY nice. As it is, I just turned down the volume on the right side, and set the controls to the left... But it clutters the screen, and uses slightly more power, all for no gain in his current use case.
--
I really love my TM-D710... When it comes time to load MY jeep with a radio, I'm defiantly going to get another Kenwood. I'll probably skip over the D710, and drop down to the TM-V71... But it's a much better radio, and I don't mind spending the extra money.
Sunday, March 3, 2013
FCC Type Approval, Part 97, And You
From time to time, a cheap radio will come out of China. These radios have been coming out with quite a bit of frequency as of late, and they will often hit the markets before they get Type Approval to be sold to licensed Amateur Radio Operators. This is perfectly legal, as Part 97 does not require Type Approval... Despite this, many Part 97 licensees still get a bit queasy if a radio doesn't bear a Type Approval sticker, and it will often be cited by critics as a reason to never touch the radios.
The lack of Type Approval happens for many reasons, but more often than not, it has nothing to do with spurious emissions... The radios seem to be of good engineering design, and will often gain type approval shortly after release. As means of an example, might I suggest the Wouxun KG-UVD1P: A very popular radio by all accounts; I carry it as my primary portable radio, and so does my wife. We are both fans; Living on a college budget, we can't afford the big name radios, and certainly can't afford the risk of them being stolen. As of late, the Beofeng UV-5R has beat the Wouxun's price point and filled the same void for a new round of users. Both models were sold initially without Type Approval stickers, and were met with skepticism; More recently, both have been carrying Part 90 Type Approval stickers, proving that no spurious emissions are produced, and the criticism was silenced.
Part 90 is a commercial radio service; Licenses are sold to businesses, schools, public safety, and government agencies. The business is licensed for the frequency, and the business gives out radios to their employees. The operators themselves are not licensed, and are not required to know FCC rules; As such, they can not be trusted with the power to modify the radios settings. No, it's nothing RF related that prevents these radios from getting type approval. Rather, it's the ease with which the radio can be modified to another frequency.
Licensees under Part 97 of the FCC rules, on the other hand, ARE individually licensed, they DO know the rules, and they then can be trusted with a frequency agile radio. Further, Part 97 operators are encouraged to experiment and to modify their radios. As such, type approval is not applicable, and is not required.
It's important to note, that in the form I received my Wouxun KG-UVD1P, it can not be used in Part 90 frequencies. In order to do so, it must have it's firmware modified. This restriction satisfies the FCC's rules governing Part 90 devices, and so it received Type Approval. In order to be used in Part 90 frequency space, a qualified technician must modify the radio's software to cover those frequencies, and enable a software lock that prevents users from modifying the settings. All the Type Approval sticker means is that the qualified tech is authorized to do so with this radio.
Don't get me wrong, Part 90 type approval is a nice addition to a radio... It proves conclusively that, as the radio comes from the factory, it doesn't produce spurious emissions But as a Part 97 user, it's far from necessary and far from something to prevent one from buying the radio.
The lack of Type Approval happens for many reasons, but more often than not, it has nothing to do with spurious emissions... The radios seem to be of good engineering design, and will often gain type approval shortly after release. As means of an example, might I suggest the Wouxun KG-UVD1P: A very popular radio by all accounts; I carry it as my primary portable radio, and so does my wife. We are both fans; Living on a college budget, we can't afford the big name radios, and certainly can't afford the risk of them being stolen. As of late, the Beofeng UV-5R has beat the Wouxun's price point and filled the same void for a new round of users. Both models were sold initially without Type Approval stickers, and were met with skepticism; More recently, both have been carrying Part 90 Type Approval stickers, proving that no spurious emissions are produced, and the criticism was silenced.
Part 90 is a commercial radio service; Licenses are sold to businesses, schools, public safety, and government agencies. The business is licensed for the frequency, and the business gives out radios to their employees. The operators themselves are not licensed, and are not required to know FCC rules; As such, they can not be trusted with the power to modify the radios settings. No, it's nothing RF related that prevents these radios from getting type approval. Rather, it's the ease with which the radio can be modified to another frequency.
Licensees under Part 97 of the FCC rules, on the other hand, ARE individually licensed, they DO know the rules, and they then can be trusted with a frequency agile radio. Further, Part 97 operators are encouraged to experiment and to modify their radios. As such, type approval is not applicable, and is not required.
It's important to note, that in the form I received my Wouxun KG-UVD1P, it can not be used in Part 90 frequencies. In order to do so, it must have it's firmware modified. This restriction satisfies the FCC's rules governing Part 90 devices, and so it received Type Approval. In order to be used in Part 90 frequency space, a qualified technician must modify the radio's software to cover those frequencies, and enable a software lock that prevents users from modifying the settings. All the Type Approval sticker means is that the qualified tech is authorized to do so with this radio.
Don't get me wrong, Part 90 type approval is a nice addition to a radio... It proves conclusively that, as the radio comes from the factory, it doesn't produce spurious emissions But as a Part 97 user, it's far from necessary and far from something to prevent one from buying the radio.
Wednesday, February 20, 2013
Encouraging experimentation while maintaining interoperability: A commentary on "Going Digital"
How does one experiment with new modes, thus advancing the hobby and the radio art, while also maintaining interoperability, a necessity in a radio service dedicated to emergency communications and the maintanance of an international community?
In this month's QST, David Sumner, ARRL CEO wrote a letter regarding Digital Modes in Amateur Radio. He said it better than I can... So I have posted the letter to my website for everyone's reading pleasure. The original can be found on Page 9 of March 2013's issue of QST.
The letter addresses the issues of interoperability and experimentation, which are concepts often at odds. Certainly regulations would promote and maintain interoperability, but such regulations would stiffle advancement; Voluntary standards don't inhibit development, but certainly don't encourage change; A free marketplace will promote advancement, as the standards that matter will be the ones that succeed - However, such a market creates a chicken and egg problem, no one will buy a technology unless the community is there, and the community may not exist unless someone buys the technology... The risk exists that seperate standards may be adopted regionally, discouraging national or international interoperability.
The problem doesn't have an obvious solution, and certainly no solution is proposed in the letter, only the suggestion that any experimentation should be done using codecs that inherently promote interoperability, such as Codec2. It's a long-shot to hope for commercial support of such an adoption... And such hope even alienates existing and growing incumbent communities, such as those surrounding DMR, P25, and D-STAR.
Still, hope should be maintained... For hope is all that will promote open experimentation and development that may someday solve these problems. Maybe the problem isn't as Mr. Sumner suggests at all... Maybe no problem exists at all: The Amateur Radio Service has the fundamental purpose of advancing the communications and technical phases of the radio art; As long as the radio service has engineers, experimenters, and just plain curious people, interoperability will come as a result.
In this month's QST, David Sumner, ARRL CEO wrote a letter regarding Digital Modes in Amateur Radio. He said it better than I can... So I have posted the letter to my website for everyone's reading pleasure. The original can be found on Page 9 of March 2013's issue of QST.
The letter addresses the issues of interoperability and experimentation, which are concepts often at odds. Certainly regulations would promote and maintain interoperability, but such regulations would stiffle advancement; Voluntary standards don't inhibit development, but certainly don't encourage change; A free marketplace will promote advancement, as the standards that matter will be the ones that succeed - However, such a market creates a chicken and egg problem, no one will buy a technology unless the community is there, and the community may not exist unless someone buys the technology... The risk exists that seperate standards may be adopted regionally, discouraging national or international interoperability.
The problem doesn't have an obvious solution, and certainly no solution is proposed in the letter, only the suggestion that any experimentation should be done using codecs that inherently promote interoperability, such as Codec2. It's a long-shot to hope for commercial support of such an adoption... And such hope even alienates existing and growing incumbent communities, such as those surrounding DMR, P25, and D-STAR.
Still, hope should be maintained... For hope is all that will promote open experimentation and development that may someday solve these problems. Maybe the problem isn't as Mr. Sumner suggests at all... Maybe no problem exists at all: The Amateur Radio Service has the fundamental purpose of advancing the communications and technical phases of the radio art; As long as the radio service has engineers, experimenters, and just plain curious people, interoperability will come as a result.
Subscribe to:
Posts (Atom)