New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup repository for clarity #19

Closed
Materdaddy opened this Issue May 6, 2014 · 18 comments

Comments

Projects
None yet
5 participants
@Materdaddy
Collaborator

Materdaddy commented May 6, 2014

I propose a major cleanup of the sketch examples and configurable bits in the example sketches themselves. I'll be working on this in a branch for your review. To me, the naming is currently a bit messy, as well as inconsistency of things like comments in the configuration section, order of things in the configuration section, etc.

To start, I'd like to propose you call the RF protocol Kommunication, or Komm for short. This can make it easy to sort the sketches. For example, anything that takes RF input, you name "Komm In" and anything that takes an input and sends the data over RF would be "Komm Out". This would make the list of sketches easily browsed as well as standardize the naming:

Komm_In_DMX_Out
Komm_In_GECE_Out
Komm_In_GwtS_Out
Komm_In_LPD6803_Out
Komm_In_Renard_Out
Komm_In_RGB_Out
Komm_In_WM2999_Out
Komm_Out_DMX_In
Komm_Out_DMX_In2*
Komm_Out_E131_In
Komm_Out_E131_In_Old*
Komm_Out_Rainbow_Test
Komm_Out_Renard_In

I also propose removing "old" sketches, like non-interrupt versions of transmitters, old versions of the sketches, or duplicate implementations (the ones I've marked with a star in the previous list).

Look for these changes in a branch I'll create called "clarity".

The reason I'll work on a branch and put this in a bug is because it'll likely affect all documentation and instruction already on forums, wikis, etc., but I think before the 2014 "rush" of display setup this should be tackled and integrated into the documentation.

@Materdaddy Materdaddy self-assigned this May 6, 2014

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy May 6, 2014

Collaborator

Along the lines of cleaning up the configurable bits, we should "standardize" the default parameters.

For example: unique ID 33, 250KBPS, listen channel 100, and NRF_TYPE RF1. My example doesn't have to be the set items, but whatever we decide should be done for all sketches.

Collaborator

Materdaddy commented May 6, 2014

Along the lines of cleaning up the configurable bits, we should "standardize" the default parameters.

For example: unique ID 33, 250KBPS, listen channel 100, and NRF_TYPE RF1. My example doesn't have to be the set items, but whatever we decide should be done for all sketches.

@Materdaddy Materdaddy changed the title from Cleanup repository for code clarity to Cleanup repository for clarity May 6, 2014

@dmcole

This comment has been minimized.

Show comment
Hide comment
@dmcole

dmcole May 21, 2014

Mater:

Though none of your examples include the word "shield," please make sure it is spelled correctly.

\dmc

dmcole commented May 21, 2014

Mater:

Though none of your examples include the word "shield," please make sure it is spelled correctly.

\dmc

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy May 21, 2014

Collaborator

Is that an inside joke?

Or the misspelling in the existing "ArduinoEthernetSheidE1_31Transmitter" sketch? Blame Greg for those. ;)

On that note, I should have some preliminary changes tonight or tomorrow that will be pushed to the clarity branch. I'll be discussing with Greg after I push changes as to the updates for the wiki and other documentation.

Collaborator

Materdaddy commented May 21, 2014

Is that an inside joke?

Or the misspelling in the existing "ArduinoEthernetSheidE1_31Transmitter" sketch? Blame Greg for those. ;)

On that note, I should have some preliminary changes tonight or tomorrow that will be pushed to the clarity branch. I'll be discussing with Greg after I push changes as to the updates for the wiki and other documentation.

@dmcole

This comment has been minimized.

Show comment
Hide comment
@dmcole

dmcole May 21, 2014

Mathew Mrosko wrote:

Or the misspelling in the existing
"ArduinoEthernetSheidE1_31Transmitter" sketch? Blame Greg for those. ;)

Take a look at the komby.com web site ... I think he has it hardwired to
spell it "sheild."

\dmc

dmcole@dmcole.net
http://www.dmcole.net

dmcole commented May 21, 2014

Mathew Mrosko wrote:

Or the misspelling in the existing
"ArduinoEthernetSheidE1_31Transmitter" sketch? Blame Greg for those. ;)

Take a look at the komby.com web site ... I think he has it hardwired to
spell it "sheild."

\dmc

dmcole@dmcole.net
http://www.dmcole.net

@komby

This comment has been minimized.

Show comment
Hide comment
@komby

komby May 22, 2014

Owner

You guys are cracking me up. Of all the spelling rules I know "i before e" but typing it is another story 😁

-----Original Message-----
From: "Dave Cole" notifications@github.com
Sent: ‎5/‎21/‎2014 4:57 PM
To: "komby/RFPixelControl" RFPixelControl@noreply.github.com
Subject: Re: [RFPixelControl] Cleanup repository for clarity (#19)

Mathew Mrosko wrote:

Or the misspelling in the existing
"ArduinoEthernetSheidE1_31Transmitter" sketch? Blame Greg for those. ;)

Take a look at the komby.com web site ... I think he has it hardwired to
spell it "sheild."

\dmc

dmcole@dmcole.net
http://www.dmcole.net

Reply to this email directly or view it on GitHub.

Owner

komby commented May 22, 2014

You guys are cracking me up. Of all the spelling rules I know "i before e" but typing it is another story 😁

-----Original Message-----
From: "Dave Cole" notifications@github.com
Sent: ‎5/‎21/‎2014 4:57 PM
To: "komby/RFPixelControl" RFPixelControl@noreply.github.com
Subject: Re: [RFPixelControl] Cleanup repository for clarity (#19)

Mathew Mrosko wrote:

Or the misspelling in the existing
"ArduinoEthernetSheidE1_31Transmitter" sketch? Blame Greg for those. ;)

Take a look at the komby.com web site ... I think he has it hardwired to
spell it "sheild."

\dmc

dmcole@dmcole.net
http://www.dmcole.net

Reply to this email directly or view it on GitHub.

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy May 22, 2014

Collaborator

Ha! I've got it corrected where I've seen it in code, comments, and filenames. Thyping is hjard...

Collaborator

Materdaddy commented May 22, 2014

Ha! I've got it corrected where I've seen it in code, comments, and filenames. Thyping is hjard...

@kingofkya

This comment has been minimized.

Show comment
Hide comment
@kingofkya

kingofkya Jun 17, 2014

Contributor

Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up

:) just kidding

Contributor

kingofkya commented Jun 17, 2014

Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up hurry up Hurry up

:) just kidding

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy Jun 17, 2014

Collaborator

Hey hey hey, progress has been made: https://github.com/komby/RFPixelControl/commits/clarity

I still have a decent TODO list with the most important thing being: TEST!

Collaborator

Materdaddy commented Jun 17, 2014

Hey hey hey, progress has been made: https://github.com/komby/RFPixelControl/commits/clarity

I still have a decent TODO list with the most important thing being: TEST!

@kingofkya

This comment has been minimized.

Show comment
Hide comment
@kingofkya

kingofkya Jun 18, 2014

Contributor

Testing who needs that :p

Contributor

kingofkya commented Jun 18, 2014

Testing who needs that :p

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy Jun 18, 2014

Collaborator

Good point... SHIP IT! ;)

Collaborator

Materdaddy commented Jun 18, 2014

Good point... SHIP IT! ;)

@dmcole

This comment has been minimized.

Show comment
Hide comment
@dmcole

dmcole Jun 18, 2014

Real artists ship.

dmcole commented Jun 18, 2014

Real artists ship.

@kingofkya

This comment has been minimized.

Show comment
Hide comment
@kingofkya
Contributor

kingofkya commented Jun 18, 2014

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy Jul 2, 2014

Collaborator

CLEANUP:
x include files, <> for other libraries and such, "" for our library
x whitespace at end of lines
x tabs vs. spaces, indentation commas, whitespace in function calls, etc.
o code commented out & unused functions
x function() -> function(void)
x move pixel pins to ADVANCED
x pixel_protocol vs. pixel_type
x double-check settings per sketch
x all: nrf_type, data_rate, listen_channel?, hard_coded_X?, pixel_type?
o double-check required headers per sketch
o too many included
x error out if no pixel type defined
x move duplicates to top dir (packets.h, ???)

o documentation (the wiki)

Rename print/test to "TEST/DEBUG"
I think the test ones should be something like test rf receiver and test transmitter

I've gone through everything I can think of here and even found a somewhat nasty little bug along the way... everything is pushed in the clarity branch as of commit c104c47.

Collaborator

Materdaddy commented Jul 2, 2014

CLEANUP:
x include files, <> for other libraries and such, "" for our library
x whitespace at end of lines
x tabs vs. spaces, indentation commas, whitespace in function calls, etc.
o code commented out & unused functions
x function() -> function(void)
x move pixel pins to ADVANCED
x pixel_protocol vs. pixel_type
x double-check settings per sketch
x all: nrf_type, data_rate, listen_channel?, hard_coded_X?, pixel_type?
o double-check required headers per sketch
o too many included
x error out if no pixel type defined
x move duplicates to top dir (packets.h, ???)

o documentation (the wiki)

Rename print/test to "TEST/DEBUG"
I think the test ones should be something like test rf receiver and test transmitter

I've gone through everything I can think of here and even found a somewhat nasty little bug along the way... everything is pushed in the clarity branch as of commit c104c47.

@Materdaddy

This comment has been minimized.

Show comment
Hide comment
@Materdaddy

Materdaddy Jul 2, 2014

Collaborator

The only thing that still needs to be done is testing everything.

So far I've tested:
Pixel sketch (no OTA) for the following pixel types: GECE, WS_2801/WS_2811. That covers GECE and technically should be OK for all FastLED controlled pixels.

Still need to test:
DMX In
DMX Out
E131 In
Renard In
Renard Out
OTA configurations

Once those are complete, we should be good to merge to master with King's changes. The minor bug fix that Komby put into master after this branch was created was previously merged by Greg onto this branch.

The wiki explanations are done as well and should be reviewed: http://learn.komby.com/wiki/58/configuration-settings

The sketches have quick descriptions and the URL to the corresponding anchor on that main configuration settings page.

Collaborator

Materdaddy commented Jul 2, 2014

The only thing that still needs to be done is testing everything.

So far I've tested:
Pixel sketch (no OTA) for the following pixel types: GECE, WS_2801/WS_2811. That covers GECE and technically should be OK for all FastLED controlled pixels.

Still need to test:
DMX In
DMX Out
E131 In
Renard In
Renard Out
OTA configurations

Once those are complete, we should be good to merge to master with King's changes. The minor bug fix that Komby put into master after this branch was created was previously merged by Greg onto this branch.

The wiki explanations are done as well and should be reviewed: http://learn.komby.com/wiki/58/configuration-settings

The sketches have quick descriptions and the URL to the corresponding anchor on that main configuration settings page.

@kingofkya

This comment has been minimized.

Show comment
Hide comment
@kingofkya

kingofkya Jul 9, 2014

Contributor

Just found this out in the US were not supposed to be using any channel above 84. That also put the over the air setup thing out of the legal range as well. So maybe channel 100 is not a good defualt.
http://playground.arduino.cc/InterfacingWithHardware/Nrf24L01

Makes senes when you compare wifi to the channels(that can go to channel 14 just not in the us)
http://doityourselfchristmas.com/forums/showthread.php?30222-What-nrf24l01-channels-are-you-using
1 - channels 1 thru 23
6 - channels 26 thru 48
11 - channels 51 thru 73

Contributor

kingofkya commented Jul 9, 2014

Just found this out in the US were not supposed to be using any channel above 84. That also put the over the air setup thing out of the legal range as well. So maybe channel 100 is not a good defualt.
http://playground.arduino.cc/InterfacingWithHardware/Nrf24L01

Makes senes when you compare wifi to the channels(that can go to channel 14 just not in the us)
http://doityourselfchristmas.com/forums/showthread.php?30222-What-nrf24l01-channels-are-you-using
1 - channels 1 thru 23
6 - channels 26 thru 48
11 - channels 51 thru 73

@kingofkya

This comment has been minimized.

Show comment
Hide comment
@kingofkya

kingofkya Jul 9, 2014

Contributor

The RF channel frequency is set by the RF_CH register according to the following formula:
F0= 2400 + RF_CH [MHz]
http://www.nordicsemi.com/jpn/content/download/2730/34105/file/nRF24L01_Product_Specification_v2_0.pdf

Greg found this.
http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf
says The FCC in the US only allows you to go from 2.4 to 2.4835 GHz
in the ISM band, which gives you 835 MHz or the first 84 channels to use (read channels 0 to 83). Any channel higher than 83 is off limits in the states, so stay away from that
frequency range if you want to avoid potential trouble with Uncle Sam and the FCC

Contributor

kingofkya commented Jul 9, 2014

The RF channel frequency is set by the RF_CH register according to the following formula:
F0= 2400 + RF_CH [MHz]
http://www.nordicsemi.com/jpn/content/download/2730/34105/file/nRF24L01_Product_Specification_v2_0.pdf

Greg found this.
http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf
says The FCC in the US only allows you to go from 2.4 to 2.4835 GHz
in the ISM band, which gives you 835 MHz or the first 84 channels to use (read channels 0 to 83). Any channel higher than 83 is off limits in the states, so stay away from that
frequency range if you want to avoid potential trouble with Uncle Sam and the FCC

@komby

This comment has been minimized.

Show comment
Hide comment
@komby

komby Jul 9, 2014

Owner

In response to these findings I am going to modify the OTA config address to channel 1 and I am going to put a upper limit in the set channel method to prevent the channels above 84. :( . we could add a configuration option to enable the use of those channels in other countries but I think we need to find a way to work within those constraints given this information.

Owner

komby commented Jul 9, 2014

In response to these findings I am going to modify the OTA config address to channel 1 and I am going to put a upper limit in the set channel method to prevent the channels above 84. :( . we could add a configuration option to enable the use of those channels in other countries but I think we need to find a way to work within those constraints given this information.

@forkineye

This comment has been minimized.

Show comment
Hide comment
@forkineye

forkineye Jul 9, 2014

I believe the nRF24L01 would classify as a Part 15 device that just uses most of the ISM band, much like all the other non-ISM stuff like 802.11 and whatnot. Given that, 2483.5-2500 would be off limits, leaving 84-99 as unusable. The EBS/BRS band allows for the usage of unlicensed Part 15 devices as well from 2500-2690 but only for periodic transmissions when used at higher power. From looking at the FCC stuff below, I think you'd be OK using the upper end (100-125) for control / configuration.

Spectrum Plan - http://reboot.fcc.gov/spectrumdashboard/searchSpectrum.seam
FCC Part 15 Rules - http://www.ecfr.gov/cgi-bin/text-idx?SID=f16ed3ff4a74afcb7fea4d9b50f90825&node=47:1.0.1.1.16&rgn=div5#47:1.0.1.1.16.3.236.21
FCC Part 15 FAQ - http://transition.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet63/oet63rev.pdf
Part 15 from a ham perspective - http://www.arrl.org/part-15-radio-frequency-devices

forkineye commented Jul 9, 2014

I believe the nRF24L01 would classify as a Part 15 device that just uses most of the ISM band, much like all the other non-ISM stuff like 802.11 and whatnot. Given that, 2483.5-2500 would be off limits, leaving 84-99 as unusable. The EBS/BRS band allows for the usage of unlicensed Part 15 devices as well from 2500-2690 but only for periodic transmissions when used at higher power. From looking at the FCC stuff below, I think you'd be OK using the upper end (100-125) for control / configuration.

Spectrum Plan - http://reboot.fcc.gov/spectrumdashboard/searchSpectrum.seam
FCC Part 15 Rules - http://www.ecfr.gov/cgi-bin/text-idx?SID=f16ed3ff4a74afcb7fea4d9b50f90825&node=47:1.0.1.1.16&rgn=div5#47:1.0.1.1.16.3.236.21
FCC Part 15 FAQ - http://transition.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet63/oet63rev.pdf
Part 15 from a ham perspective - http://www.arrl.org/part-15-radio-frequency-devices

@komby komby closed this Jan 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment