Current Cost Support Forum

A support forum for Current Cost users, partners and developers. Covering hardware, software and web.
Site Announcements

The support forum is moderated Monday to Friday, UK time. To submit a support ticket, please email: helpme [at] currentcost .com

It is currently Wed Jun 19, 2013 6:20 am

View unanswered posts | View active topics


Board index » Hardware » Transmitters

All times are UTC [ DST ]



Post new topic Reply to topic  Page 2 of 3
  [ 22 posts ]  Go to page Previous  1, 2, 3  Next
  Print view Previous topic | Next topic 
Author Message
WieserSoftwareLtd
PostPosted: Tue Sep 27, 2011 6:23 am 
Offline
User avatar

Joined: Fri Sep 09, 2011 10:13 am
Posts: 20
Location: Cambridge, England
Here in the UK, it's the opposite.

We receive £0.433 per kWh generated, + and additional £0.030 for each kWh assumed to be exported (50% in most cases, as they don't bother fitting an export meter).

UK electricity for me in the east of england costs £0.09777 kWh during daylight hours if you're on a two rate system, so it's more beneficial to be using the electricity rather than exporting it.

I don't think that will be a problem in the winter, but the summer is more difficult.

Regarding live_sol, are you planning to sell it or for it to be freeware?
Top
 Profile  
 
johnlee
PostPosted: Tue Sep 27, 2011 12:12 pm 
Offline

Joined: Tue Jul 05, 2011 11:46 am
Posts: 35
SeekerAfterTruth wrote:
johnlee wrote:
My 'mission' in live_sol is to do the best estimate for a house with solar, of the power saved and 'wasted' (ie going back to grid at 0 credit) wrt the user, and to get the best estimate of the billable power each day.

Hmm, I was going to talk to you about the terminology.

To you, power back to the grid is "wasted"; to me it is "exported". That's because I receive $0,66 for each Kwh I export. I only pay $0.32/KwH in peak times (M-F 7am-11pm) and $0.10/Kwh for off-peak. That makes my mission to use as little power as possible while the sun shines and shift as much import to the wee small hours as I can (e.g. run dishwasher on a timer). I hope Live_sol will accommodate both missions.


In uk one can normally only get money (only a fraction of the import tariff) for exported power by going to a tariff (there are zillions of different tariffs, and elec. cos in uk) that is much more expensive per kwh used, rather defeating the object of saving dosh, hence 'wasted'. btw I used 'mission' rather ironically - not a term I like, everyone has to have a 'mission' it seems these days - live_sol currently does not care about tariffs - it just does the power calcs hourly/daily of house, solar, 'wasted', 'saved', 'billable' (assuming as in uk that you lose the power returned to grid), and also 'grid' which is the net power from/to grid. Things are a bit more complicated for your time variant tariffs, but of course you could use the hourly .csv file - to do the 'bill' calcs - I could of course add tariffs to live_sol, but later maybe....

I wish we could have these discussion in an appropriate forum - I suggested to cc n times 'solar' - we may be the only ones reading this - but cc seem never to respond (or moderate!) this... Hello current cost are you there? John
Top
 Profile  
 
jack_kelly
PostPosted: Thu Aug 09, 2012 9:25 am 
Offline

Joined: Thu Aug 09, 2012 8:39 am
Posts: 5
Location: London, UK
This is a very interesting thread! Sorry I'm arriving a little late!

I have a very large Current Cost system running in my house in the UK:

  • 26 Individual Appliance Monitors
  • 3 CT clamps
  • 3 EnviR monitors (two with v1.29 firmware, one with v1.48 firmware)

Let me share some data with you. But before I do, I should quickly summarise what I think my data demonstrates: basically, I think my data supports the view mentioned above that the current generation of CC transmitters do not do any carrier detection or collision avoidance before transmitting. Neither do they wait for an acknowledgement. Each transmitter appears to just blindly squirt its packet onto the RF carrier. If a collision occurs then the data is lost for ever.

OK. Here's the data. It takes a bit of explaining:

Code:
port      = /dev/ttyUSB0
DSB       = 00012
Version   = CC128-v1.48

                                         |---PERIOD STATS (secs)---|
               LABEL CHAN CCsens WATTS    MEAN    MAX    MIN   LAST  COUNT RADIOID LOCATIONS
  Kitchen_DownLights   14      0     0    8.53  586.2    5.5    6.1  16628    1709 {'/dev/ttyUSB0 0': 16628}
Toaster_or_KitchenAi   15      1     1   10.43 1517.4    5.8    6.1  13598    1919 {'/dev/ttyUSB0 1': 13598}
Kettle_or_SandwichTo   16      2     0    8.81  641.7    5.8    6.1  16086    3828 {'/dev/ttyUSB0 2': 16086}
CoffeeMaker_or_Bread   17      3     0    8.61 1185.5    5.9    6.1  16469    3953 {'/dev/ttyUSB0 3': 16469}
           Microwave   18      4     0    8.50  232.5    5.8    6.1  16673    2069 {'/dev/ttyUSB0 4': 16673}
              Fridge   19      5     0    9.58  483.9    5.8    6.1  14788    2148 {'/dev/ttyUSB0 5': 14788}
       Kitchen_Radio   20      6     2    9.53  484.1    5.8    6.1  14873    2514 {'/dev/ttyUSB0 6': 14873}
          DishWasher   21      7     0    9.19 2195.3    5.6   12.3  15424    3913 {'/dev/ttyUSB0 7': 15424}
        Kitchen_Lamp   22      8     0   58.29 8219.8    6.1    6.1   2432    3319 {'/dev/ttyUSB0 8': 2432}
              Boiler   32      9     0    7.11   54.2    5.5    6.0  19932   895/1 {'/dev/ttyUSB0 9': 19932}
        SolarThermal   33      9     0    7.11   54.2    3.7    6.0  19932   895/2 {'/dev/ttyUSB0 9': 19932}


port      = /dev/ttyUSB1
DSB       = 00030
Version   = CC128-v1.29

                                         |---PERIOD STATS (secs)---|
               LABEL CHAN CCsens WATTS    MEAN    MAX    MIN   LAST  COUNT RADIOID LOCATIONS
          *Aggregate   99      0   216   10.92  459.0    5.9   12.4  12983      77 {'/dev/ttyUSB1 0': 12983}
              Laptop   23      1    26    7.82  787.7    5.8   12.2  18130     795 {'/dev/ttyUSB1 1': 18130}
           DesktopPC   24      2     2    7.65  103.6    5.8    6.1  18530    2246 {'/dev/ttyUSB1 0': 0, '/dev/ttyUSB1 2': 18529}
          Office_LCD   25      3    71    7.95  226.6    5.8    6.1  17842    2422 {'/dev/ttyUSB1 8': 0, '/dev/ttyUSB1 3': 17841}
         Office_HiFi   26      4     0    8.04  202.4    5.9    6.1  17625     361 {'/dev/ttyUSB1 4': 17625}
Office_Lamp1_and_Lam   27      5     0    7.63  464.1    5.7    6.1  18588    3455 {'/dev/ttyUSB1 5': 18588}
             Printer   28      6     0    7.94  305.4    5.8    6.1  17845    1935 {'/dev/ttyUSB1 6': 17845}
          GigEswitch   29      7     5    7.85  141.0    5.8   12.3  18069    3759 {'/dev/ttyUSB1 7': 18069}
                 Fan   30      8     0    7.84  751.2    5.8    6.1  18087     309 {'/dev/ttyUSB1 8': 18087}
      BatteryCharger   31      9     0    7.62  220.0    5.8    6.1  18597    1660 {'/dev/ttyUSB1 9': 18597}


port      = /dev/ttyUSB2
DSB       = 00208
Version   = CC128-v1.29

                                         |---PERIOD STATS (secs)---|
               LABEL CHAN CCsens WATTS    MEAN    MAX    MIN   LAST  COUNT RADIOID LOCATIONS
          *Aggregate   01      0   252    9.45   72.7    3.8   12.4  14972      77 {'/dev/ttyUSB2 0': 14972}
                  TV   05      1     0    7.79  892.8    5.9    6.1  18159    2553 {'/dev/ttyUSB2 7': 0, '/dev/ttyUSB2 8': 0, '/dev/ttyUSB2 1': 18157}
                 Amp   06      2     0    7.48  654.2    4.2   12.2  18902    4092 {'/dev/ttyUSB2 2': 18901, '/dev/ttyUSB2 0': 0}
           Subwoofer   07      3     0    7.23  122.5    3.4    6.1  19570    3834 {'/dev/ttyUSB2 3': 19570}
                HTPC   08      4     3    7.84  386.0    4.6    6.1  18035    4029 {'/dev/ttyUSB2 4': 18035}
      WashingMachine   09      5     0    8.85  208.7    5.5   12.3  15992    2143 {'/dev/ttyUSB2 5': 15992}
           AdslModem   10      6     6    8.02  268.7    5.3    6.1  17647    2833 {'/dev/ttyUSB2 6': 17647}
            LR_Lamp1   11      7     0    7.55  556.4    3.4   18.3  18747    1798 {'/dev/ttyUSB2 7': 18747}
            LR_Lamp2   12      8     0    7.61  177.4    4.9   12.2  18592    1097 {'/dev/ttyUSB2 8': 18592}
            LR_Lamp3   13      9     0    7.40  116.0    4.4    6.1  19119     606 {'/dev/ttyUSB2 9': 19119}


The data above shows stats from all three EnviRs.
Let's go through the columns one-by-one, starting on the left:

  • LABEL is the human-readable label (where "Aggregate" means the whole-house power measured by a CT clamp at the fuse box)
  • CHAN ignore this
  • CCsens = the "Current Cost Sensor" number, i.e. the <sensor> number reported in the XML
  • WATTS = the most recent power reading
  • PERIOD STATS = this is the section that's probably most interesting to this discussion. This section describes some basic statistics for the time between consecutive data packets for each transmitter. If everything was working perfectly then there would be a 6 second gap between each transmitter's packet. But data gets lost so sometimes the gap is far, far longer than six seconds, as these statistics demonstrate. Note that for most transmitters, the mean period between packets is fairly respectable: 7-10 seconds. But this mean hides some truly horrible maximum delays: some transmitters see fail to be heard for several thousand seconds (i.e. several thousand seconds elapse between two consecutive data packets from that transmitter.)
  • COUNT = the total number of packets received for this channel
  • RADIOID = the radio ID reported by the transmitter (note that these are all unique) in the <id> element of the XML
  • LOCATIONS = this is an interesting one. My code uses the radioID as the unique ID of the transmitter, not the <sensor> (CCsens) on the EnviR. The reason I basically ignore the <sensor> number is because, occasionally, a single IAM can jump onto a <sensor> that it's not supposed to be on! For example, the TV's IAM has appeared on '/dev/ttyUSB2 7' (i.e. the EnviR connected to serial port ttyUSB2 on <sensor> 7), and sensor 8 and sensor 1 (it's supposed to only appear on sensor 1!). This "cross talk" is, I believe, one possible outcome of a collision (although the far more likely outcome of a collision is that data from one or all collided packets are lost). This cross-talk seems to be more prevalent in firmware version 1.29 than 1.48.

So, basically, on a system as large as mine, it seems inevitable that quite a lot of data will be lost. I'm planning to reduce the number of IAMs to the bare minimum.

Why do I have 30 IAMs? Because I'm doing a PhD on "smart meter disaggregation (non-intrusive load monitoring)" and I need the "ground truth" regarding what each appliance is doing.

My data are available here and my Python logging code is here (both are in a state of flux at the moment but should settle down in a week or so).
Top
 Profile  
 
jack_kelly
PostPosted: Fri Sep 07, 2012 10:32 am 
Offline

Joined: Thu Aug 09, 2012 8:39 am
Posts: 5
Location: London, UK
Just a quick followup...

After making my own receiver for Current Cost transmitters, taking apart an EnviR and an IAM, and sniffing SPI data from an EnviR, I am 99.999% certain that CC IAMs only contain a transmitter and hence cannot do collision avoidance or recover from dropped packets. Hence, basically, it seems that it's not possible to use CC IAMs if you require reliable data transmission.

The good news is that the EDF EcoManager Wireless Transmitter Plugs (made by Current Cost) are much better behaved. They contain transceivers and only transmit after being pinged by the base station; hence avoiding collisions. (But the EDF kit isn't compatible with the CC kit).

Full details in the "Current Cost" category on my blog: http://jack-kelly.com/taxonomy/term/121
Top
 Profile  
 
jcims
PostPosted: Tue Oct 16, 2012 8:29 pm 
Offline

Joined: Tue Oct 16, 2012 7:58 pm
Posts: 6
- removed , dupe of following post -


Last edited by jcims on Fri Oct 26, 2012 1:28 am, edited 1 time in total.

Top
 Profile  
 
jcims
PostPosted: Tue Oct 16, 2012 8:30 pm 
Offline

Joined: Tue Oct 16, 2012 7:58 pm
Posts: 6
Hi Folks,

I just received my EnviR recently and am tinkering with the use of an inexpensive software defined radio running on a raspberry pi to decode the RF transmissions directly rather than go through the receiver.

I'm trying to correlate the information I'm seeing with what folks on here have surmised and I'm having difficulty lining things up. I'm extremely new to DSP so it's entirely possible that my rather hacky FSK demodulator is not correct, but I'm also wondering if the RF module is using some encapsulation that isn't visible on the SPI bus. Here is some raw output as I see it coming in over the proverbial non-wire.

Code:
33 33 33 33 A4 57 55 55 34 B2 D5 54 B2 AA D5 4D 4C CB 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4C D5 4D 52 AD 55 55 55 54 DE E4
33 33 33 33 A4 57 55 55 34 B2 D5 54 B2 AA D5 4D 4D 2D 55 55 55 54 45 24
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 52 D5 4D 4C D5 55 55 55 54 83
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4C D5 4D 4D 35 55 55 55 54 24
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 54 D5 4D 4D 4B 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4C D5 4D 4C AB 55 55 55 54 9A E
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 52 D5 4D 4D 4D 55 55 55 54 5B 3C
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 54 D5 4D 4D 35 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 52 D5 4D 4D 4B 55 55 55 54 19 2B B2
33 33 33 33 A4 57 55 55 34 B2 D5 54 B2 B2 D5 4D 4D 55 55 55 55 54 F
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 52 D5 4D 4D 35 55 55 55 54 96
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4C D5 4D 52 AD 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 B2 AA D5 4D 4D 33 55 55 55 54 37
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 52 D5 4D 4D 2D 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 54 D5 4D 4D 33 55 55 55 54 C8
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4A D5 4D 4D 2D 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4C D5 4D 4C D5 55 55 55 54 F5 43
33 33 33 33 A4 57 55 55 34 B2 D5 54 B2 AA D5 4D 4C D3 55 55 55 54
33 33 33 33 A4 57 55 55 34 B2 D5 54 AD 4A D5 4D 4D 2D 55 55 55 54 5D F9


One thing you will likely note early on is the preamble of 0x55 isn't...it's 0x33 in this case, with 0x55 reserved for the end of the transmission. (Note that things get ugly at the end as the squelch kicks in). Also, unfortunately, my data cable hasn't arrived yet so I don't know what I can correlate with in the data.

Also, if you look at some of this in binary, the manchester encoding breaks in several areas quite reliably:

Code:
00110011 00110011 00110011 00110011 10100100 01010111 01010101 01010101 00110100 10110010 11010101 01010100 10101101 01001100 11010101 01001101 01001100 11010011 01010101 01010101 01010101 01010100
00110011 00110011 00110011 00110011 10100100 01010111 01010101 01010101 00110100 10110010 11010101 01010100 10100101 01011010 10101010 10101010 10101010 10101000 11011000 00010101
00110011 00110011 00110011 00110011 10100100 01010111 01010101 01010101 00110100 10110010 11010101 01010100 10101101 01001100 11010101 01001101 01001100 11001011 01010101 01010101 01010101 01010100


There's a number of occurrences of '11' for example deep in the packet, which seems to be a no-no(?)

For what it's worth, here's a .wav file of the signal demodulated through narrowband FM - https://public-xrp.s3.amazonaws.com/envir.wav

Here's what it looks like in Audacity:

Image

Any thoughts?

Thanks!

Bob
Top
 Profile  
 
jack_kelly
PostPosted: Fri Oct 26, 2012 10:25 am 
Offline

Joined: Thu Aug 09, 2012 8:39 am
Posts: 5
Location: London, UK
Hiya Bob,

Sorry for not replying to your quesions on my blog - I've been away at a conference for the past few days, sorry!

If you haven't done so already, I'd definitely recommend posting to the JeeLabs forum, e.g. this thread: http://forum.jeelabs.net/comment/9316

Well done for taking the brave step to trying to use a software-configurable radio for this stuff: sounds like fun! Unfortunately I have zero experience with software radio so I probably wont be much help...

I'm afraid I'd have to agree that your data doesn't look like Current Cost data. As far as I know, all Current Cost data starts with 55 2D D4 (the 55 is the preamble, the 2DD4 is the sync word). And yes, you're right, the only valid bit pairs in a Manchester-encoded signal should be 01 or 10 (so any pairs of 11 or 00 are illegal and suggest something is broken).

I've had a quick tinker with your waveform and can't make heads nor tails of it, sorry. My only suggestion would be to find out precisely what your Current Cost TX is sending over the air by sniffing FSK data directly from the FSK input pin on the Current Cost transmitter's RFM02 module (but be very careful to isolate your computer from the transmitter; and I'd recommend taking apart a battery powered TX rather than an IAM). You might be able to use the audio-input on a sound card to sample from the transmitter's FSK pin (after isolating appropriately of course... maybe using an audio transformer?) I think the Current Cost transmitter sends a sequence of logical zeros and ones to the transmitter over the FSK input pin; ready for the transmitter to create an FSK signal.

Good luck - let us know how you get on!
Top
 Profile  
 
jcims
PostPosted: Fri Oct 26, 2012 8:42 pm 
Offline

Joined: Tue Oct 16, 2012 7:58 pm
Posts: 6
jack_kelly wrote:
Hiya Bob,

Sorry for not replying to your quesions on my blog - I've been away at a conference for the past few days, sorry!

Hi Jack! No worries, I felt like a vagrant posting all of those questions but didn't have a good outlet at the time. It seems I've gained human status on these boards so I'll keep the conversation on here. :)
Quote:
If you haven't done so already, I'd definitely recommend posting to the JeeLabs forum, e.g. this thread: http://forum.jeelabs.net/comment/9316

Will do.
Quote:
I'm afraid I'd have to agree that your data doesn't look like Current Cost data. As far as I know, all Current Cost data starts with 55 2D D4 (the 55 is the preamble, the 2DD4 is the sync word). And yes, you're right, the only valid bit pairs in a Manchester-encoded signal should be 01 or 10 (so any pairs of 11 or 00 are illegal and suggest something is broken).

The thing I'm speculating is that the HopeRF devices apply their own encoding...possibly parity bits or whatnot (encoding is not my specialty for sure). Now that I've realized that the temperature is coming from the receiver and not the transmitter, I'm doing a better job of narrowing down what is coming from the Sensable. It's quite predictable and with a bit of effort I'm fairly certain i'll get it figured out.

Thanks for the suggestions on tapping the RFM, I might give that a go to see how the data correlates. Or i'll just keep chipping away at this.. :) Will let you know how it goes either way.
Top
 Profile  
 
jcims
PostPosted: Sun Oct 28, 2012 4:19 pm 
Offline

Joined: Tue Oct 16, 2012 7:58 pm
Posts: 6
Well, the forum successfully nuked a long winded reply, so I'll cut to the chase.

I printed out the binary output along with serial output and was able to locate the wattage data in the RF transmissions:

Code:
9:27:26   69.4    0287    0669    <snip> 11001011 01001101 0   0101010 10101100 10101101 0101010   1 0   0101010 10110011 00101101 0100110   0 <snip>
                                                                0 0 0  0 0 0 1  0 0 0 1  1 1 1 1  (287)   0 0 0  0 0 1 0  1 0 0 1  1 1 0 1   (669)
9:26:24   69.5    0288    0670    <snip> 11001011 01001101 0   0101010 10101100 10110010 1010101   1 0   0101010 10110011 00101101 0101001   0 <snip>
                                                                0 0 0  0 0 0 1  0 0 1 0  0 0 0 0  (288)   0 0 0  0 0 1 0  1 0 0 1  1 1 1 0   (670)
8:56:55   70.3    3123    2410    <snip> 11001011 01001101 0   0101011 01001010 10110100 1011010   1 0   0101011 00101100 11010011 0011001   0 <snip>
                                                                0 0 0  1 1 0 0  0 0 1 1  0 0 1 1 (3123)   0 0 0  0 0 1 0  1 0 0 1  1 1 1 0  (2410)


Everything was shifted over by one bit. I'm not sure how much of the above is Manchester encoded and how much isn't. Regardless, I'm now able to cherry pick the bits I'm interested in and seem to be having some success. Here is some 'debug' output comparing serial and RF data:

Code:
Serial: 11:10:29,70.4,00703,00783  RF: 703, 783
Serial: 11:10:39,70.4,00682,00787  RF: 682, 787
Serial: 11:10:49,70.4,00552,00782  RF: 552, 782
Serial: 11:11:00,70.3,00546,00788  RF: 546, 788
Serial: 11:11:10,70.4,00533,00783  RF: 533, 783
Serial: 11:11:20,70.4,00642,00788  RF: 0, 0
Serial: NA,NA,NA,NA  RF: 642, 788
Serial: NA,NA,NA,NA  RF: 689, 793
Serial: 11:11:41,70.3,00543,00787  RF: 543, 787
Serial: 11:11:51,70.4,00672,00789  RF: 672, 789
Serial: 11:12:01,70.4,00520,00782  RF: 520, 782
Serial: NA,NA,NA,NA  RF: 0, 0
Serial: NA,NA,NA,NA  RF: 0, 0
Serial: 11:12:11,70.4,00522,00781  RF: 522, 781
Serial: 11:12:22,70.4,00593,00782  RF: 593, 782
Serial: 11:12:32,70.4,00871,00788  RF: 871, 788
Serial: 11:12:42,70.4,00736,00786  RF: 736, 786
Serial: 11:12:52,70.4,00613,00784  RF: 613, 784
Serial: 11:13:02,70.3,00780,00787  RF: 780, 787
Serial: NA,NA,NA,NA  RF: 0, 0
Serial: 11:13:13,70.4,00795,00794  RF: 795, 794
Serial: 11:13:23,70.4,00782,00789  RF: 782, 789
Serial: 11:13:33,70.4,00809,00784  RF: 809, 784
Serial: 11:13:44,70.4,02970,02767  RF: 2970, 2767
Serial: 11:13:55,70.4,02761,02759  RF: 2761, 2759
Serial: 11:14:06,70.3,02644,02739  RF: 2644, 2739
Serial: 11:14:17,70.4,02787,02739  RF: 2787, 2739
Serial: 11:14:28,70.4,02776,02744  RF: 2776, 2744
Serial: 11:14:38,70.4,02854,02750  RF: 2854, 2750
Serial: 11:14:49,70.3,02769,02745  RF: 2769, 2745
Serial: 11:15:00,70.4,02883,02749  RF: 2883, 2749


Anything marked "NA,NA" indicates that there were two successive RF transmissions received with no serial data. Given that most of them don't decode RF data either, I'm assuming those are other ISM devices in the house opening squelch.

Anyway, I'm going to keep this running for a bit, clean up the code, and punch a copy up to github or something. The SDR i'm using is a little $20 'RTL-SDR' dongle hanging off of a raspberry pi (where this code is running). Start here if you're interested: http://sdr.osmocom.org/trac/wiki/rtl-sdr
Top
 Profile  
 
jack_kelly
PostPosted: Mon Oct 29, 2012 12:10 pm 
Offline

Joined: Thu Aug 09, 2012 8:39 am
Posts: 5
Location: London, UK
Great work - thanks for the update!
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 3
  [ 22 posts ]  Go to page Previous  1, 2, 3  Next

Board index » Hardware » Transmitters

All times are UTC [ DST ]

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group