Existing SoC designs already have more than one processor; it is just all squished together on one die. It is one chip, but it would be the whole normal nest of chips if it wasn't in an integrated package.
Vendors will say anything, never believe that breathless crap. They hate rules, even when they have more influence over the rules than the consumers who the rules supposedly protect.
They won't still be saying that later if you're trying to buy a chip from them that includes DRM. It turns out that is hard, and expensive, and changing the microcontroller that is already on the SoC to use a stored value instead of getting the radio gain from the init code is easy.
There was one locally who wore it every day, back in the `80s. He was known around the neighborhood as Zeus. There were Pastafarians even before there was a manifesto or a fake founder. It goes back to the 1960s, at least.
And of course the counter point is that it is illegal for a police officer to order you to remove religious attire, (they would need a court order even if they have a compelling interest) so for the purpose of identification prior to any probable cause for an invasive search they have a hard time showing that the attire is not included in what they have to identify. If they can't tell her to take it off, how is having a picture of the naked skin underneath going to assist in identification? If they were requiring the license to have electronic biometric data, such as a fingerprint, and to provide that to the officer for scanning, that would clearly be legal. And since measures like that are possible, that don't violate the known and bona fide religious restrictions, then that is what they would have to do under the traditional requirement of taking the least suppressive action when balancing against 1st amendment concerns.
The main reason there isn't extensive case law and precedent here is that most women with a religious prohibition for covering their faces are not allowed by their husbands to drive. Generally speaking, if her family lets her drive they're usually going to let her just wear a hijab, which leaves the face uncovered. And the other reason, biometrics are new, even in the case of fingerprints where it is new that the police could do that using a non-invasive scanner, and have a digital version stored in the license. I don't think there are any recent cases that explored the actual alternatives that the government has and how that affects the required balancing.
I will fight that civil war on the side of the Union, I refuse to be you, to make myself identifiable as you, or even to make myself identifiable to you. And if you want me out of the supermarket because I refuse to tell you my name, you're welcome to bring it up with the store manager. I have a feeling one of us is going to get kicked out of the store.;)
That's the cheapo GPS chip that makers are using. ~$40 on a breadboad module, but more like $5 as an OEM part. Calculates and stores "up to 3 days" of satellite position, then uses a lookup table. That is part of why new units still take a long time to get a cold fix; they're calculating satellite positions.
This has been a standard feature since around 10-15 years ago when they started advertising improved urban accuracy. If you're not predicting locations, you'd have to do a cold fix every time you walked past a building! It would be basically unusable downtown. Like in the old days! Back then it was also largely unusable in the forest; you'd have to find a clearing, or else remain stationary for a couple minutes, to get a fix on a cheap unit. That is why back then for serious outdoor use people were dropping $500 on dedicated GPS units that had the predictive routines, and regular GPS was intended mostly for highway auto use where the sky is usually visible.
Almost everything predictive uses Kalman filters. That is not a sign of low quality. It is a system of using predictions and expected error rates to overcome noise. If the result quality is low, it is not because of using a Kalman filter it is because of having a low quality prediction routine, or an inaccurate expected noise level. There is nothing about orbital mechanics or radio propagation that makes Kalman filters a poor fit; actually, it is nearly the ideal case for them; the noise will have a Gaussian distribution.
You're just speculating on some unknown that you worry they might be "forced" to do one thing or another, whereas the story, and the analysis such as that you responded to, is telling you the answers. The unknowns you are speculating about are not unknowns, they are known knowns. They are not being forced to use any particular implementation.
You seem to entirely discount that DRM is very hard to do, and even harder to do in a way that successfully inconveniences anybody. They're not going to spend millions of dollars engineering that for no reason. That is what you should be hearing yourself say when you talk about "signed firmware blobs." You're talking about increasing the cost of the hardware, and engaging in a huge amount of engineering work, to avoid a small change in firmware to place the specific settings for radio gain and modulation level behind write-once fuse bits, which are cheap and easy to add to their existing designs. The runtime code doesn't even change. The init code might change a small amount. They can lock down that one setting really well and really easy, with minimal increase in cost. Locking down the OS is orders of magnitude more disruptive and expensive, and is likely to fail anyways.
Don't speculate from ignorance just to avoid reading the story or learning about the issues implicated.
"it can be more than 20%" -Yeah, it can be an infinite number of %, if the actual distance travelled is zero, and the random error is not.
The infinite case is probably the most common, too, since the real motion of an apparently stationary device is smaller than the granularity of the position reading. People are just sleeping peacefully, not even realizing that their GPS positional error is infinite.
If you model the orbital mechanics of the satellite properly and use that as a feedforward step in the filter, then you remove another source of bias. Most receivers don't because there's just no real need to introduce the extra complexity, and small, correlated errors don't matter all that much.
When I'm evaluating GPS modules, most of them advertise approximately this feature. Without some sort of product testing saying it doesn't work, I'm not going to believe it is a real contemporary problem. A decade ago? Probably true for consumer products. Now? No. And you don't have to model the orbital mechanics, with model being a verb, you can simply have a model, (a noun) and look up the expected position in the table. "Everybody" predicts satellite position these days. And worrying about complexity is funny; it is software, not hardware. They already wrote the software long ago for the higher end units. It doesn't add much complexity to use the better version. And in fact, even low end modules are now including jammer protections. Why can they offer that in a low end model? Because the existing satellite prediction capability makes jammer protection a lot easier. As easy as a Kalman Filter.;)
Mostly. But the problem is in the time period you're averaging; if you take a longer average, the positional error would still average out. The reason it makes the zigzag is that the resolution we demand for our movements is different than the granularity of the noise errors.
Users want the small movements that are smaller than the expected noise level of the sensor. It might be possible to simply also take a longer average, and normalize the A-B distance based on that, while preserving the zigzag. That way the map would show small movements, but the distance would be an average at a different scale instead of a sum of the mapped legs. Then instead of the error case being normal movement, if you're really zigzagging it would under-report distance. Especially if you have an additional sensor and can detect the stopped condition, and average those with other readings in the same spot. Most GPS devices do have an accelerometer.
Of course, most of my GPS use is zigzagging in the forest foraging wild mushrooms, so my distance calculation accuracy might go down. The way it is now, if you zigzag (or turn) at a higher rate than the GPS signal is wobbling then it does average out pretty well. You have to sustain an A->B path for the error to be consistently less direct.
Trying to add new protections that guard the firmware is a lot harder than taking away the command that the OS sends to the radio firmware.
The problem isn't the "firmware." One problem is language; people are describing the router OS as "firmware," but it isn't; that is regular software. Being installed on flash drive doesn't turn it into "firmware." But there is a hardware radio, which in most cases has real firmware. Currently, that firmware just does whatever the processor tells it to do. All they have to do in many cases is alter the radio firmware to use compiled-in radio power and modulation limits.
The ones that are harder are where it is a single System on Chip, and the radio firmware is not accessible to the device programmer. But in that case, any attempt to lock it down would require adding an external microcontroller. An extra controller that limits the output power is going to be a lot easier than one that attempts to implement some sort of DRM scheme. But the real change will come easy; the SoC vendors will just make a tiny, tiny change so that the memory address for the gain can't be altered. That is what will really happen; the companies making the routers won't even have to change anything. It is already normal for microcontrollers to have a fuse bit that can be programmed to prevent further changes to certain parts of memory. This is what that is for. And it won't affect the OS, which will still have to be able to receive security updates.
There is no reason for an extra OS, because any additional microcontroller will only be managing the radio, and there is no reason to use an OS for that; you can just program the firmware to run directly.
All they really have to do though is compile the max gain into the existing firmware instead of letting the OS set it on boot. They have to cut/paste a couple lines from one.h file to another. Horrors. The rules on the max output wattage don't change very often; historically, I don't think it has ever been increased. The total net benefit of that being configurable has been zilch.
People handwaving about things getting "locked down" are a bit breathless. There is no reason companies are going to spend extra money on engineering hours to lock down stuff other than the radio gain and modulation settings.
The router stuff isn't being prevented or restricted in any way, those are simply the devices where some models were not following the rules. Basically, they moved too much of the radio init code into software out of laziness. The radio is a hardware radio, though, not software; so we're just talking about moving OS driver code into firmware, and all that gets moved is the init. There is no way they're going to save money by trying to "lock down" the OS, which is not really doable anyways.
Remember, software defined radio is more expensive than hardware radios, because of the processing requirements. So the radios were already all hardware. That is why the FCC engineers are a bit surprised and disappointed in the public and the doomsday speculation.
Cheapest devices will continue to suck, news at 11?
Better devices will get better, because they'll have a modular design by following the actual implementation recommendations they gave. They just want the radio block not to have the gain turned up by the main processor. That is it. That is all. Honestly, this is what they should have been doing already under the old guidance. The "new" rule is just a friendlier way than saying, "You've been doing it wrong for 10 years" and leave everybody worrying about fines, or fighting over what the old rules really said. They were never allowed to sell devices that the user could turn up over the output limit; they were always supposed to be unable to be turned up by the user without physical modification.
And that is better for people that want to violate the rules, too, because external, modular amplifiers that are on the black market now are much, much stronger than the modifications that people can do in firmware. Everybody wins, except the cheapskates.
If you disagree with analysis by a plain, "what if I disagreed," don't be surprised if there is no response other than "you're wrong."
No analysis means you didn't have any ideas to contribute, and probably didn't understand the issues.
Me not repeating what you say is not me censoring you. It never is, it never was, it never will be. So you can make the bare assertion, but it won't have any value.
A publication can't "censor" you unless they're doing something like suing you to stop your speech. Their speech is their speech. They can't be changing or limiting your speech by their own. Speech is additive, not subtractive. Whatever you said, you still said it. They literally can't censor you by including or not including your speech. That would require action other than the publication of their own choice words.
A person might make a case that selective partial reproduction could be censorship, but that wouldn't apply here because it was completely withdrawn, not altered. They simply stopped repeating what he said, and announced that they no longer endorsed that speech.
Still using xterm. I used a few that claimed to be "light weight" but they all sucked. Over time, xterm has continued to stay the same size and speed, with the same (rather complete) feature set, while competitors have grown and grown and now xterm is lighter weight than anything with even 50% of the feature set.
# ps ax | grep xterm | grep -v grep | wc -l 15
I don't like tabs because they serve the same purpose as "workspaces" or "virtual desktops" and I can just layout related terms on their own screen. Then I can see all the related information at once, instead of having page back and forth and memorizing just to compare things.
And for remote sessions, I just run screen on the remote side. The cases where I'd want tabs would be on a small screen, like a laptop, but that basically implies that I'm fixing a remote system over ssh.
Driving I just stay out of their way, but in the evening I usually walk and I often see an excessively slow driver and shout, "Don't drink and drive!" About half of them slam on their brakes instantly, before realizing they should "act normal" and keep driving.
And of course the corollary is also true; tailgating leads to slower drivers as the person in front can only reduce their speed to reduce the required safe space behind their vehicle.
You're one of these false pedants who doesn't realize that quoting something irrelevant in authoritative detail is not helpful or informative.
Look up the law about Neighborhood Electric Vehicles. I'll give you a hint: you quoted a thing about highways. Neighborhood Electric Vehicles are not operated on highways, they are operated on streets with a speed limit of 35 or less, and they themselves are limited to 25 mph. They're intended to be slow moving vehicles that sometimes are slower than other traffic.
Cops are legally required to have a real reason for a stop; with a computer driver, there is no reasonable concern that the computer is drunk.
If you read as many words of the story as you pasted from google you'd have realized that was about highways. And if you're licensed in any State you'd know that rules on city streets are different than rules on highways.
If you read slashdot more often, you'd already know that in California they let the self-driving cars be programmed to go +10mph over the "limit." But the ones they are actually using that way are the ones that drive on regular roads. This kind is a Neighborhood Electric Vehicle, not a general purpose car.
Cops pull people over for "driving too slowly" regardless of safety reasons all the time. And if you're from out of town they fine you. They didn't ticket the google car because it would have brought scrutiny, not because it was legal to drive that slowly on the road.
Partly true; the cops don't know the law, so it is only because the cop decided not to write a ticket that the department didn't have to drop it.;)
But there is no question at all that it is legal for a Neighborhood Electric Vehicle to drive 24 in a 35. Absolutely legal. The traffic stop was improper, caused entirely by the cop not knowing the laws related to the type of vehicle he was stopping.
Slashdot Mirror
Existing SoC designs already have more than one processor; it is just all squished together on one die. It is one chip, but it would be the whole normal nest of chips if it wasn't in an integrated package.
Vendors will say anything, never believe that breathless crap. They hate rules, even when they have more influence over the rules than the consumers who the rules supposedly protect.
They won't still be saying that later if you're trying to buy a chip from them that includes DRM. It turns out that is hard, and expensive, and changing the microcontroller that is already on the SoC to use a stored value instead of getting the radio gain from the init code is easy.
There was one locally who wore it every day, back in the `80s. He was known around the neighborhood as Zeus. There were Pastafarians even before there was a manifesto or a fake founder. It goes back to the 1960s, at least.
And of course the counter point is that it is illegal for a police officer to order you to remove religious attire, (they would need a court order even if they have a compelling interest) so for the purpose of identification prior to any probable cause for an invasive search they have a hard time showing that the attire is not included in what they have to identify. If they can't tell her to take it off, how is having a picture of the naked skin underneath going to assist in identification? If they were requiring the license to have electronic biometric data, such as a fingerprint, and to provide that to the officer for scanning, that would clearly be legal. And since measures like that are possible, that don't violate the known and bona fide religious restrictions, then that is what they would have to do under the traditional requirement of taking the least suppressive action when balancing against 1st amendment concerns.
The main reason there isn't extensive case law and precedent here is that most women with a religious prohibition for covering their faces are not allowed by their husbands to drive. Generally speaking, if her family lets her drive they're usually going to let her just wear a hijab, which leaves the face uncovered. And the other reason, biometrics are new, even in the case of fingerprints where it is new that the police could do that using a non-invasive scanner, and have a digital version stored in the license. I don't think there are any recent cases that explored the actual alternatives that the government has and how that affects the required balancing.
I will fight that civil war on the side of the Union, I refuse to be you, to make myself identifiable as you, or even to make myself identifiable to you. And if you want me out of the supermarket because I refuse to tell you my name, you're welcome to bring it up with the store manager. I have a feeling one of us is going to get kicked out of the store. ;)
http://www.americasfreedomfigh...
Quit your whining, we already have religious freedom for real religions. This is about religious freedom for satirical fake religions.
http://www.adafruit.com/datash...
That's the cheapo GPS chip that makers are using. ~$40 on a breadboad module, but more like $5 as an OEM part. Calculates and stores "up to 3 days" of satellite position, then uses a lookup table. That is part of why new units still take a long time to get a cold fix; they're calculating satellite positions.
This has been a standard feature since around 10-15 years ago when they started advertising improved urban accuracy. If you're not predicting locations, you'd have to do a cold fix every time you walked past a building! It would be basically unusable downtown. Like in the old days! Back then it was also largely unusable in the forest; you'd have to find a clearing, or else remain stationary for a couple minutes, to get a fix on a cheap unit. That is why back then for serious outdoor use people were dropping $500 on dedicated GPS units that had the predictive routines, and regular GPS was intended mostly for highway auto use where the sky is usually visible.
Almost everything predictive uses Kalman filters. That is not a sign of low quality. It is a system of using predictions and expected error rates to overcome noise. If the result quality is low, it is not because of using a Kalman filter it is because of having a low quality prediction routine, or an inaccurate expected noise level. There is nothing about orbital mechanics or radio propagation that makes Kalman filters a poor fit; actually, it is nearly the ideal case for them; the noise will have a Gaussian distribution.
That is why it is 90% sugar. That sweet and sour dessert sauce? Those aren't lumps, those are cranberries.
The pie might have also had a little fruit. Worse, the sugar in it is probably from beets. Which are a vegetable.
Wait until somebody tells you that there are concentrated vegetables in the gravy. You might reconsider the stomach staples at that point.
You're just speculating on some unknown that you worry they might be "forced" to do one thing or another, whereas the story, and the analysis such as that you responded to, is telling you the answers. The unknowns you are speculating about are not unknowns, they are known knowns. They are not being forced to use any particular implementation.
You seem to entirely discount that DRM is very hard to do, and even harder to do in a way that successfully inconveniences anybody. They're not going to spend millions of dollars engineering that for no reason. That is what you should be hearing yourself say when you talk about "signed firmware blobs." You're talking about increasing the cost of the hardware, and engaging in a huge amount of engineering work, to avoid a small change in firmware to place the specific settings for radio gain and modulation level behind write-once fuse bits, which are cheap and easy to add to their existing designs. The runtime code doesn't even change. The init code might change a small amount. They can lock down that one setting really well and really easy, with minimal increase in cost. Locking down the OS is orders of magnitude more disruptive and expensive, and is likely to fail anyways.
Don't speculate from ignorance just to avoid reading the story or learning about the issues implicated.
"it can be more than 20%" -Yeah, it can be an infinite number of %, if the actual distance travelled is zero, and the random error is not.
The infinite case is probably the most common, too, since the real motion of an apparently stationary device is smaller than the granularity of the position reading. People are just sleeping peacefully, not even realizing that their GPS positional error is infinite.
Your accelerometer can give you a very good reading of zigzagginess that can bias the correction accurately.
If you model the orbital mechanics of the satellite properly and use that as a feedforward step in the filter, then you remove another source of bias. Most receivers don't because there's just no real need to introduce the extra complexity, and small, correlated errors don't matter all that much.
When I'm evaluating GPS modules, most of them advertise approximately this feature. Without some sort of product testing saying it doesn't work, I'm not going to believe it is a real contemporary problem. A decade ago? Probably true for consumer products. Now? No. And you don't have to model the orbital mechanics, with model being a verb, you can simply have a model, (a noun) and look up the expected position in the table. "Everybody" predicts satellite position these days. And worrying about complexity is funny; it is software, not hardware. They already wrote the software long ago for the higher end units. It doesn't add much complexity to use the better version. And in fact, even low end modules are now including jammer protections. Why can they offer that in a low end model? Because the existing satellite prediction capability makes jammer protection a lot easier. As easy as a Kalman Filter. ;)
Mostly. But the problem is in the time period you're averaging; if you take a longer average, the positional error would still average out. The reason it makes the zigzag is that the resolution we demand for our movements is different than the granularity of the noise errors.
Users want the small movements that are smaller than the expected noise level of the sensor. It might be possible to simply also take a longer average, and normalize the A-B distance based on that, while preserving the zigzag. That way the map would show small movements, but the distance would be an average at a different scale instead of a sum of the mapped legs. Then instead of the error case being normal movement, if you're really zigzagging it would under-report distance. Especially if you have an additional sensor and can detect the stopped condition, and average those with other readings in the same spot. Most GPS devices do have an accelerometer.
Of course, most of my GPS use is zigzagging in the forest foraging wild mushrooms, so my distance calculation accuracy might go down. The way it is now, if you zigzag (or turn) at a higher rate than the GPS signal is wobbling then it does average out pretty well. You have to sustain an A->B path for the error to be consistently less direct.
You had me going until you pretended you actually shave that thing. You've still got rancid cranberries from last Thanksgiving in it!
Trying to add new protections that guard the firmware is a lot harder than taking away the command that the OS sends to the radio firmware.
The problem isn't the "firmware." One problem is language; people are describing the router OS as "firmware," but it isn't; that is regular software. Being installed on flash drive doesn't turn it into "firmware." But there is a hardware radio, which in most cases has real firmware. Currently, that firmware just does whatever the processor tells it to do. All they have to do in many cases is alter the radio firmware to use compiled-in radio power and modulation limits.
The ones that are harder are where it is a single System on Chip, and the radio firmware is not accessible to the device programmer. But in that case, any attempt to lock it down would require adding an external microcontroller. An extra controller that limits the output power is going to be a lot easier than one that attempts to implement some sort of DRM scheme. But the real change will come easy; the SoC vendors will just make a tiny, tiny change so that the memory address for the gain can't be altered. That is what will really happen; the companies making the routers won't even have to change anything. It is already normal for microcontrollers to have a fuse bit that can be programmed to prevent further changes to certain parts of memory. This is what that is for. And it won't affect the OS, which will still have to be able to receive security updates.
There is no reason for an extra OS, because any additional microcontroller will only be managing the radio, and there is no reason to use an OS for that; you can just program the firmware to run directly.
All they really have to do though is compile the max gain into the existing firmware instead of letting the OS set it on boot. They have to cut/paste a couple lines from one .h file to another. Horrors. The rules on the max output wattage don't change very often; historically, I don't think it has ever been increased. The total net benefit of that being configurable has been zilch.
People handwaving about things getting "locked down" are a bit breathless. There is no reason companies are going to spend extra money on engineering hours to lock down stuff other than the radio gain and modulation settings.
The router stuff isn't being prevented or restricted in any way, those are simply the devices where some models were not following the rules. Basically, they moved too much of the radio init code into software out of laziness. The radio is a hardware radio, though, not software; so we're just talking about moving OS driver code into firmware, and all that gets moved is the init. There is no way they're going to save money by trying to "lock down" the OS, which is not really doable anyways.
Remember, software defined radio is more expensive than hardware radios, because of the processing requirements. So the radios were already all hardware. That is why the FCC engineers are a bit surprised and disappointed in the public and the doomsday speculation.
Cheapest devices will continue to suck, news at 11?
Better devices will get better, because they'll have a modular design by following the actual implementation recommendations they gave. They just want the radio block not to have the gain turned up by the main processor. That is it. That is all. Honestly, this is what they should have been doing already under the old guidance. The "new" rule is just a friendlier way than saying, "You've been doing it wrong for 10 years" and leave everybody worrying about fines, or fighting over what the old rules really said. They were never allowed to sell devices that the user could turn up over the output limit; they were always supposed to be unable to be turned up by the user without physical modification.
And that is better for people that want to violate the rules, too, because external, modular amplifiers that are on the black market now are much, much stronger than the modifications that people can do in firmware. Everybody wins, except the cheapskates.
If you disagree with analysis by a plain, "what if I disagreed," don't be surprised if there is no response other than "you're wrong."
No analysis means you didn't have any ideas to contribute, and probably didn't understand the issues.
Me not repeating what you say is not me censoring you. It never is, it never was, it never will be. So you can make the bare assertion, but it won't have any value.
A publication can't "censor" you unless they're doing something like suing you to stop your speech. Their speech is their speech. They can't be changing or limiting your speech by their own. Speech is additive, not subtractive. Whatever you said, you still said it. They literally can't censor you by including or not including your speech. That would require action other than the publication of their own choice words.
A person might make a case that selective partial reproduction could be censorship, but that wouldn't apply here because it was completely withdrawn, not altered. They simply stopped repeating what he said, and announced that they no longer endorsed that speech.
He's just too high to figure out the teams.
Still using xterm. I used a few that claimed to be "light weight" but they all sucked. Over time, xterm has continued to stay the same size and speed, with the same (rather complete) feature set, while competitors have grown and grown and now xterm is lighter weight than anything with even 50% of the feature set.
# ps ax | grep xterm | grep -v grep | wc -l
15
I don't like tabs because they serve the same purpose as "workspaces" or "virtual desktops" and I can just layout related terms on their own screen. Then I can see all the related information at once, instead of having page back and forth and memorizing just to compare things.
And for remote sessions, I just run screen on the remote side. The cases where I'd want tabs would be on a small screen, like a laptop, but that basically implies that I'm fixing a remote system over ssh.
Driving I just stay out of their way, but in the evening I usually walk and I often see an excessively slow driver and shout, "Don't drink and drive!" About half of them slam on their brakes instantly, before realizing they should "act normal" and keep driving.
And of course the corollary is also true; tailgating leads to slower drivers as the person in front can only reduce their speed to reduce the required safe space behind their vehicle.
You're one of these false pedants who doesn't realize that quoting something irrelevant in authoritative detail is not helpful or informative.
Look up the law about Neighborhood Electric Vehicles. I'll give you a hint: you quoted a thing about highways. Neighborhood Electric Vehicles are not operated on highways, they are operated on streets with a speed limit of 35 or less, and they themselves are limited to 25 mph. They're intended to be slow moving vehicles that sometimes are slower than other traffic.
Cops are legally required to have a real reason for a stop; with a computer driver, there is no reasonable concern that the computer is drunk.
If you read as many words of the story as you pasted from google you'd have realized that was about highways. And if you're licensed in any State you'd know that rules on city streets are different than rules on highways.
Sounds like what you "know" about "history" is nazi propaganda.
If you read slashdot more often, you'd already know that in California they let the self-driving cars be programmed to go +10mph over the "limit." But the ones they are actually using that way are the ones that drive on regular roads. This kind is a Neighborhood Electric Vehicle, not a general purpose car.
Cops pull people over for "driving too slowly" regardless of safety reasons all the time. And if you're from out of town they fine you. They didn't ticket the google car because it would have brought scrutiny, not because it was legal to drive that slowly on the road.
Partly true; the cops don't know the law, so it is only because the cop decided not to write a ticket that the department didn't have to drop it. ;)
But there is no question at all that it is legal for a Neighborhood Electric Vehicle to drive 24 in a 35. Absolutely legal. The traffic stop was improper, caused entirely by the cop not knowing the laws related to the type of vehicle he was stopping.